Consider using a UUID to identify handlers. about dogma

[jmalloc]

After further discussion with @koden-km it's probably not desirable to use the type name directly. Perhaps supplying both a name and a UUID via the configurer could be appropriate:

func Identity(name, uuid string)

c.Identity("transfer", "66edc02f-7dde-4594-aee7-9ff958d8186b")

Furthermore, to avoid confusion with "instance ID", perhaps the UUID could be referred to as the "handler key" or something like that.

[jmalloc]

Can you guys please proof-read this. This is an example of the way the spec language would change:

type AggregateConfigurer interface {
	// Identity sets unique identifiers for the handler.
	//
	// It MUST be called exactly once within a single call to Configure().
	//
	// The name is a human-readable identifier for the handler. Each handler
	// within an application MUST have a unique name. Handler names SHOULD be
	// distinct from the application's name. The name MAY be changed over time
	// to best reflect the purpose of the handler.
	//
	// The key is an immutable identifier for the handler. Its purpose is to
	// allow engine implementations to associate ancillary data with the
	// handler, such as application state or message routing information.
	//
	// Each entity within an application, including the application itself, MUST
	// have a unique key. The key MUST NOT be changed. The RECOMMENDED key
	// format is RFC 4122 UUID, generated when the handler is first implemented.
	//
	// Both the name and the key MUST be non-empty UTF-8 strings consisting
	// solely of printable Unicode characters, excluding whitespace. A printable
	// character is any character from the Letter, Mark, Number, Punctuation or
	// Symbol categories.
	Identity(name string, key string)

How are we feeling about the name key for this new identifier?

[jmalloc]

Current thinking is to remove configurer Name() method in favour of Identity(uuid string), and to use the Go type name anywhere that a human readable name is needed.

[jmalloc]

We should probably give applications the same treatment as handlers. They too have a Name() method currently.

[koden-km]

Sounds reasonable. Will that also be useful for applications communicating across the network?

[jmalloc]

Possibly. For Verity specifically it won't matter much because inter-application routing will be discovered dynamically anyway.

[jmalloc]

So, I think I'll press ahead with a prototype of Identity(name, key) method replacing Name().

[koden-km]

The doc sounds good and using key seems fine to me.

[jmalloc]

что ты думаешь @danilvpetrov?

[danilvpetrov]

I think that this is very clear and accessible explanation. Makes total sense to me.

Я абсолютно согласен с предложенной трактовкой.

[jmalloc]

классно, я сделаю ПР.

[jmalloc]

I've submitted the PR, please note that the language has changed slightly from the example I posted above. It also includes ADR-9 to document the decisions we've made here.