-2

Recently, I asked about my difficulties in finding the boundaries of aggregates here and I recently reinterpreted it and rid it of business features and now it sounds like this:

In many sources, examples are given of the allocation of aggregates. Most often in these examples of one aggregate one or more important behavioral objects are used and several objects representing background information. For example Orderas behavioral object and PaymentWay, Location as background information or Delivery behavioral object and Location, DeliveryWay, Caras background and so on.

My question is how to fill out background information if we can not be attached to specific instances of the aggregates ? I mean, it seems to me that I can not write as follows: order.AddNewPaymentWay(location) because I do not want to create an Order, I just want to fill in the background information.

cephei
  • 143
  • 1
  • 8
  • What do you want to fill if it is not an instance of Order? – Stop harming Monica Nov 24 '17 at 11:50
  • If I got it right, by background objects you mean value objects, right? If so, what's the problem with creating aggregate root with all required properties, that might be represented as value objects? – Vadim Samokhin Nov 24 '17 at 11:57
  • @Zapadlo The problem is when you try to add just `Locatio`, `Address` for example in admin panel you do not need to create `Order` you just need to add reference Information (спавочная информация) )). I hope you are aware of the rules of the aggregate. – cephei Nov 24 '17 at 12:14
  • Well, in this case more probably than not it means that Location and Address are separate entities, forming their own aggregate roots. Their life-cycle is not governed by Order aggregate. They even are created at different times. So they are not part of Order aggregate. They can be referenced by it by their ids. – Vadim Samokhin Nov 24 '17 at 12:54
  • @Zapadlo The fact of the matter is that if we will follow this logic then we rarely find applications in which the aggregate is more than one object – cephei Nov 24 '17 at 13:25
  • If by one object you mean entity -- then it's great. Small aggregates are easier and more robust than the big ones: http://www.informit.com/articles/article.aspx?p=2020371&seqNum=3 – Vadim Samokhin Nov 24 '17 at 13:54
  • @Zapadlo The main goal of the aggregate is to increase the level of abstraction in order to simplify the application. If we split aggregates to entities we will lose this advantage – cephei Nov 24 '17 at 14:05
  • Agree, but I guess almost everybody wrote about preferring small aggregates. Big aggregates are great -- they are higher-level abstractions. But it doesn't come for free as you might guess -- they are more complex. And concerning your case if you want to keep both location in an order aggregate you're left with the only option of creating an order when you want to add a new location, which is apparently wrong. Besides, what happens when you'll need to use the concept of location somewhere else? – Vadim Samokhin Nov 24 '17 at 14:22
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/69244/discussion-between-zetetic-and-zapadlo). – cephei Nov 25 '17 at 05:13

1 Answers1

0

I can not write as follows: order.AddNewPaymentWay(location) because I do not want to create an Order, I just want to fill in the background information.

You do that by creating background information objects (PaymentWay, Location, DeliveryMethod) just as you've already described, or by creating a single data object that holds all of the background information. You don't need an Order object to do that.

The main goal of the aggregate is to increase the level of abstraction in order to simplify the application. If we split aggregates to entities we will lose this advantage

The main goal of the aggregate is to combine data and logic together so that they can be treated as a single unit. You might have several entities that combine together to form this aggregate, and that's perfectly fine.

Another way of looking at the aggregate is to consider it more or less equivalent to a unit of work or a database transaction. When you execute the Save() method on that aggregate object, the object must have all of the data and all of the logic that it needs to complete that transaction in an atomic, consistent, isolated and durable way.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • I can do on everyone but the question is how to do it correctly in terms of DDD. "The main goal of the aggregate is to combine data and logic together so that they can be treated as a single unit". if you answer the question why you need to combine into aggregates, then you will come to my statement. Transaction is another vector which tends to split aggregates. – cephei Nov 25 '17 at 05:28
  • 2
    There's no such thing as "correctly." Software development is a continuous exercise in tradeoffs; you can't expect to read a book, learn the rules and follow it like a lawyer. It doesn't work that way. What you should be doing is evaluating your approach and refining it until it is optimal for your specific situation. – Robert Harvey Nov 25 '17 at 06:12
  • Here I agree with you – cephei Nov 25 '17 at 06:45