Reputation: 59
I have 3 subdomains that logically were splitted into 3 Bounded Contexts (and on 3 independed microservices)
Project BC
with aggregate Project
User BC
with aggregate User
Customer BC
with aggregate Customer
And need to perform action "export projects to XLS file". But in export file besides project information I need also to have user name and customer name for every project. Project
aggregate root has only user ID and customer ID as reference to other bounded contexts models
Additionally were decided to use Anti-corruption Layer pattern for relationship between BC. So it means that Project BC
should have necessary information for User and Customer
Questions:
Project BC
has User and Customer objects as independent aggregates or these should be entities inside Project
aggregate?Project
aggregate, (2) inside application service or (3) make independent aggregate with export model and business logic? The idea of (3) is that export has also own parameters and objects (format, exported fields etc) that can defined as entities for aggregateUpvotes: 0
Views: 45
Reputation: 57194
"Aggregates aren't real".
An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes.
If you are exporting projects into an excel file, you aren't making data changes, you are just copying data.
So separation of concerns tells us to keep the aggregates out of it - we don't want to make reporting harder by entangling it with a bunch of data change concerns, and we definitely don't want to make data change harder by entangling it with a bunch of reporting concerns.
If all of the information you need is available in a single relational database, then "just" join the tables and select the data that you need.
Domain Driven Design does not require that me make simple things difficult just for the sake of ceremony.
Upvotes: 0