Search code examples
domain-driven-designone-to-manyaggregateroot

Which is aggregate root. Recipient or Cost ? DDD


I'm creating an application to analyze my expenses. I want to implement in a DDD way. My 2 main entities are : CounterPart(Recipient/Sender) and Expense(Cost/Income)

class diagram

It seems logical to take CounterPart as an aggregate root but I need to do a lot of actions on Expense directly like marking it as a daily, monthly, ... expense.

Can I only interact on expense using the counterPart ?


Solution

  • Your Aggreggate Root in DDD is driven by your Business requirements. You need to have a good understanding of business before deciding your aggreggate root.

    In your case, there is one to many relationship between CounterPart and Expense. Can Expense exist outside of CounterPart? If not, it probably makes sense to have CounterPoint as your Aggreggate Root.

    If you need to manipulate your Expense, you would then need to expose operations such as AddExpenseToCounterPart, SetExpenseToDaily etc on CounterPart.

    If, however, your Domain is simple (or anaemic) without any complex business rules.I would ask why to even go for DDD?