rita
rita copied to clipboard
Establish convention for how subjects map to entity, aggregates/deciders
There are a few terms to disambiguate:
- entity - ID of the logical entity in the domain
- aggregate (as defined by DDD) - a discrete model of the entity acting as a consistency boundary. There can be multiple aggregates per logical entity, each owning different subsets of the idealized representation
- Although aggregate has its roots in OOP and many examples include methods for behavior, I use this term interchangeably with state and treat both as simply data structures. If there are methods, it would be in assistance to working with the data, but
- subject - a NATS subject which encodes the ID and aggregate type
- decider - as defined here, although functional in design, it represents the set of components necessary to load, evolve, and decide command and yield events. a decider is 1:1 with an aggregate (a specific model of state + commands), so I also use these somewhat interchangeably depending on the context
Convention could be based on the subject, e.g. orders.123.address
which encodes the entity and the aggregate/decider name. An optional fourth token should be used when a stream needs to be consistently sharded using subject mapping partition
function, e.g. orders.123.address.5
.