On persisting an aggregate #21
Replies: 1 comment
-
Great questions. Aggregates are meant to encapsulate the repository calls. This is an area of the framework I leave to the developer. Since there isn't much that I can offer generically in the framework, one would write their own data access patterns and encapsulate them in the Aggregate. That said, I have some patterns I will create examples with as I expand the documentation for DomainJS. Currently, at creation time, I use a factory method or service to create an entity and then pass it as the root entity for the aggregate. I do this because I didn't set the root parameter in the constructor as an optional. I am contemplating how to approach this in the best way for the framework. It is pretty much one of the last pieces I am investigating the best approach for. |
Beta Was this translation helpful? Give feedback.
-
How does an Aggregate handle persistence of the object model?
Inject a handler to the constructor of the aggregate and then have the created and updated hooks to call repository.save()?
What about loading the object model from repository at creation time?
Also, multiple objects within an aggregate may be updated while processing a user's request. How is the consistency and integrity of the entire aggregate managed by this aggregate?
Beta Was this translation helpful? Give feedback.
All reactions