Comments (12)
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.
from dogma.
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?
from dogma.
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.
from dogma.
We should probably give applications the same treatment as handlers. They too have a Name()
method currently.
from dogma.
Sounds reasonable. Will that also be useful for applications communicating across the network?
from dogma.
Possibly. For Verity specifically it won't matter much because inter-application routing will be discovered dynamically anyway.
from dogma.
So, I think I'll press ahead with a prototype of Identity(name, key)
method replacing Name()
.
from dogma.
The doc sounds good and using key
seems fine to me.
from dogma.
что ты думаешь @danilvpetrov?
from dogma.
I think that this is very clear and accessible explanation. Makes total sense to me.
Я абсолютно согласен с предложенной трактовкой.
from dogma.
классно, я сделаю ПР.
from dogma.
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.
from dogma.
Related Issues (20)
- Consider allowing recording an event after destroying an aggregate instance. HOT 3
- Pass AggregateRoot directly to HandleCommand() HOT 1
- Document best practices, conventions and common usage problems. HOT 16
- Rename `AggregateCommandScope.Destroy()` to something more appropriate. HOT 2
- Review process message handler API. HOT 11
- Consider adding `Now()` method to scope interfaces. HOT 1
- Specify allowed lengths for all variable-length data types. HOT 5
- Rename `RegisterAggregate()` etc to `RegisterAggregateHandler()`
- Consider allowing commands to start processes.
- Enforce all identity keys to be UUIDs.
- ValidatableMessage not calling Validate() HOT 1
- Improve interface for declaring message types in `XXXConfigurer` interfaces.
- Remove `EventRecorder` interface.
- Use separate interfaces for each message type.
- Require all messages to implement `Validate()`
- Require all messages to implement `MessageDescription()`.
- Cancellation of timeouts HOT 1
- Placeholder functional options
- Changes to semantics of ending a process.
- Require engines to pass clones of messages to handlers.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dogma.