Comments (5)
I think we probably want to have a hard minimum that engines should support, and then recommended maximums for application developers.
from dogma.
We need to come up with lengths that we're comfortable adding to the spec. Just to get the ball rolling ...
message descriptions
I don't think there's any obvious length here, but given that they're intended to be written to a log we'd generally want them to fit in a "single line", however long that may be. Perhaps we could suggest that they SHOULD be a maximum of 120 characters. We'll probably truncate them when storing in the database, but I'm not sure if that's really relevant to the spec at all. We could say that the engine MAY truncate or compact the messages for display purposes.
identity keys
We already suggest that the keys be UUIDs, and I can't really think of a strong use case for using anything other than a UUID, so we could even consider mandating that keys MUST be a UUID. Short of that I'd probably make the limit here the same as for aggregate/process instance IDs just for consistency/ease.
identity names
These should probably be treated a bit like type names in an arbitrary language - long enough to be descriptive, but not so long as to become unwieldy. We might want to suggest that they SHOULD be <50 characters or so, but require engines to support more. In practice these could be truncated and not impact engine operation (since it's the key that is definitive) but I am disinclined to allow for such truncation since they are still an identifier.
aggregate & process instance IDs
We definitely want to at least allow for UUIDs, but also have the "compound" keys that we construct from multiple other UUIDs, so we want to allow for fairly long identifiers, however, the longer we allow the bigger and "slower" database indexes become in engines like Verity. I'm inclined to cap this one at something like 128 bytes - plenty long enough for a few UUIDs, etc, chained together, but still shorter than an average SQL database's VARCHAR column width.
from dogma.
I don't see any reasons not to specify those limits. Should those limits should be presented as recommendations for engine implementations or as hard requirements?
from dogma.
Your suggested limits seem fine. I like the idea of recommended limits without them being hard limits. That allows users to still do what they need but guides them to the intended usage.
from dogma.
- As of Dogma v0.12.0 identity keys must be RFC 4122 UUIDs.
- As of Dogma v0.12.1 identity names must be between 1 and 255 bytes in length
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
- 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.