thiel_florian <at> web.de [domaindrivendesign] <domaindrivendesign <at> yahoogroups.com>
2016-05-12 13:56:53 GMT
I know my topic is not new and was discussed many times before. I read a lot but not sure whether I am going the best path. So I will place this topic here again with another concrete example.
In the sales department we work with orders. Obviously this is, what a customer orders.
A) Understanding an order with its items:
Our stakeholder often fall back and say: We need an order and order items. But this is only because of giving the “thing” an order number to talk about. Like brackets around all order items. So our understanding in the dev-Team is, the order items are aggregates and we will do something to group then by an order number.
We think of order items as aggregates, because a customer will never request an order with three items in it. Furthermore he will order three articles with a specific number. It is only for communication reasons that a number for these three items makes it easier. What do you think about that?
B) Conflict with sub-entity within order-item-aggregate
Think of order item. This is an article in a specific quantity a customer would like to have. Order item is an aggregate. Assigned to the order item there are multiple “call off”. A call off describes when the customer requests a certain quantity and whether it must be delivered (DDP) or whether it will be fetched (“ex works”). Actually call off is an aggregate on its own. Here is our conflict:
1. Sum of quantities for all call off must be less than or equal to order item quantity. So making call off an sub entity of order item seems to be the best choice, than making it an own aggregate.
2. On the other side call off will be referenced in the dispatch department. This is, because every call off leads at least to an “goods issue request” in the dispatch department. But refering to book from Eric Evans it is absolutely not allowed to reference a sub-entity - except for a single operation. It is only allowed to reference aggregates.
We are afraid of having 90% our objects being an aggregate and placing domain logic not within the aggregates but within services around two or more aggregates.
From what I have already read and got as responses from experts like Paul Rayner I should start to think about "call off" as an "domain event". Okay, it's no problem to imagine that order item will have an "customer requested quantity"-Event or something like this.
Problem is when leaving bounded context of let's say "customer care". In dispatch department it is no problem to imagine that this domain event can lead to an action and new aggregate there. At this point I do not need a reference to the "call off"/domain event. But when dispatch has problems or work is done, sales department needs to be informed that "call off" needs attention or is done and possibly order item can be given to "invocement"-bounded-context?
Is it okay, when aggregate in dispatch holds composed key on order item and sub-entity / aggregate leaf? What other possibilitites do you see? Must "call off" be an aggregate and a domain-service must check sum of call off quantities agains order item? Is this something for the "Process Manager" presented to me the first time at the DDD Europe in Belgium by Mathias Verraes?
I will be very happy getting a lot of ideas and responses. Thank you very much for reading my story .
Posted by: thiel_florian <at> web.de