Hi,
trying to understand the basics of modelling for Axon.
I have an aggregate (Project) that has lots of sub entities members, sub-project (different entity not a recursive project) etc…
Basically all decision making has to be routed through the base aggregate. You cannot really add, delete or do anything to entities for aggregate project without knowing the state of the project (closed, launched etc…).
If I model the project as aggregate and my entites as part of that aggregate (in maps and lists) and use the axonserver as eventstore I get many aggregates with aggregateSequenceNumber over 1700. Spooling that many events back when loading a project aggregate could affect perfomance I guess? I also guess that is possible to mitigate by configuring a cache? But is this a preferred solution?
If I instead model some of the entities as separate aggregates and get access between the root aggregate and the sub aggregates using queries I get few aggregats with more than 100 events/aggregate.
I cannot find any recommendation anywhere in the documentation. Could someone please advice on what is the best tradeoff?
Cheers,
Fredrik
My opinion on on your problem is not to try and treat Aggregates as large root Entities (model classes). In short, I avoid placing Entities inside my aggregates and when appropriate store the ids and/or the respective properties of those entities for the Aggregate itself.
Hopefully someone will provide for a meaningful and useful response.
Hi,
I think that the recommendation generally is to try to design aggregates to be “as small as possible” for performance and scalability reasons. Whether the size of the event stream is a problem depends on the specific application. How frequently are the aggregates modified? By how many concurrent users? What latencies are acceptable? Can frequently accessed aggregates be kept in in-memory cache? Axon does support Snapshots as a way to speed up loading of large event streams, so you could also have a look at that if you decide that you need to optimize.
Nevertheless, and without knowing anything about your domain, I would question the assumption that almost all commands need to be validated by the project aggregate. I find that it’s often possible to relax the (implied) consistency requirements by asking yourself (or even better, the domain experts) some questions about the participating actors and use cases: Why/when is a project launched/closed and how/when are members made aware of this state change? What is the expected behaviour if a sub-project is added just before a the main project is closed? And so on…
In the actual physical world transactions between people are rarely immediately consistent, so modelling your aggregates as closely as possible to concrete real-life entities can usually help in identifying where the strong consistency boundaries actually lie. Here’s a good series of articles and talks that discusses these things in some detail: http://dddcommunity.org/library/vernon_2011/
Faik
You are absolutely correct and that will make a better design I reckon.
I will take that to hart and make a flat structure.
Thank you!
Cheers,
Fredrik