Skip to main content

5 docs tagged with "Aggregate"

View all tags

Origin

In domain-driven design, bounded contexts and context maps are essential elements of strategic modelling. A bounded context defines a linguistic boundary within which a specific ubiquitous language is used consistently. Each aggregate is owned and managed by a single bounded context and domain events for that aggregate should only be emitted from within that context.

Shared Kernel

In a microservice architecture, multiple services may need to maintain a local view of aggregates owned by other services. For example, consider the BankAccount aggregate discussed in the aggregate documentation. Let’s say we update the BankAccount aggregate to reference a user by ID rather than by name. This is a more realistic setup for systems operating across service boundaries. The BankAccount aggregate is owned by the accounting service, but now depends on the User aggregate owned by the user service to reference user information.

Snapshotting

DugongJS reconstructs aggregates state by loading its domain events from the domain event repository and applying them in order. As the number of events grows, this rehydration process becomes slower. To mitigate this, DugongJS supports snapshotting. This is an optional optimization that allows you to cache and restore aggregate state more efficiently. It is opt-in per aggregate and you may enable it from the start or at a later time if performance should become an issue.