How to design aggregate roots for stock tracking model using DDD?

Question

For the following anemic domain model:

• stock: id, code, description, total_amount - specific stock type, and total_amount is calculated to speedup views showing remaining quantity,
• stock_arrival: id, date, document_id - stock arrival event, and references document with details using document_id for bureaucracy/history reasons,
• stock_arrival_line: stock_arrival_id, stock_id, quantity, unit_price - line describing specific stock change on arrival, including pricing,
• stock_removal: id,... - stock removal event,
• stock_removal_line: stock_removal_id, stock_id - line describing specific stock change on removal event,
• ... other change stock events ...

The anemic domain model has following relation constraints:

• stock_arrival_line:stock_id references stock:id,
• stock_arrival_line:stock_arrival_id references stock:id,
• stock_removal_line:stock_id references stock:id,
• stock_removal_line:stock_removal_id references stock:id,

---

Probably, stock and stock_arrival/stock_removal should be aggregate roots,..

Domain above shows, that there's many-to-many relationship between stock and stock_arrival/stock_removal via mapping tables, and that's the main part which concerns me.

The invariants should be defined only on aggregate root and it's internals. Therefore, within stock aggregate, there's need to store stock_arrival_line/stock_removal_line, in order to make stock aggregate complete.

However, the same applies to aggregate roots stock_arrival/stock_removal, that they need to contain within themselves stock_arrival_line/stock_removal_line respectively, in order to make these aggregate roots about events complete.

When following DDD, where should these ...line(s) belong? Should they be duplicated? Or, should it be modeled completely differently?

---

Disclaimer for possible close-voters: I had finished computer science studies, and there was heavy split between data and operations. Recently, I've stumbled across domain driven design, and started learning it, and it's quite different approach, and I'm lost about this many-to-many relationship and aggregate roots.

Answer 1

The Stock should be the aggregate root in your case. StockArrival and StockRemoval can extend the event class and you can rename it to StockArrived and StockRemoved with respect to the past tense specific of the event type object. Also, the events can contains a list of Line instances (where Line is an abstract class which is subclassed by StockArrivalLine and StockRemovalLine ) and reference the Stock aggregate through the stockId attribute from the event class. In real life, a Line on a document doesn't have an id, but an orderNumber. In case of id attribute from the Line class, the name sounds very synthetic, I think that you should rename it to orderNumber.