I will give two examples. Omit even some important things from DDD now, examples are intended to show the essence of the issue.

How best to do in terms of DDD?

There are two root aggregates, the seller and the announcement. The seller can edit the ad in these examples:

one.

If the models need to reflect real business logic. That Seller changes the ad. changeAdvertName() client layer calls the changeAdvertName() and changeAdvertCost() methods of the Seller aggregate. This gives such an advantage as, say, access checking, we can see that the Seller can only change its Adverts . This is the first option how to do it.

  //Client layer call seller.changeAdvertName(name) //AR Seller class Seller{ adverts changeAdvertName(advertId, name){ adverts[advertId].changeName(name) } changeAdvertCost(advertId, cost){ adverts[advertId].changeCost(cost) } } //AR Advert class Advert{ name cost changeName(name){ this.name = name } changeCost(cost){ this.cost = cost } }

2

Another option is where the client layer will call changeName and changeCost directly on the Advert aggregate. I see this implementation more often in various examples.

  //Client layer call advert.changeName(name) //AR Advert class Advert{ name cost changeName(name){ this.name = name } changeCost(cost){ this.cost = cost } }

Are both options valid in DDD? And which one is more correct and logical in terms of DDD?

  • I have already answered this question: stackoverflow.com/questions/45927675/… - Yury Golikov
  • one
    Then interpret this answer here in order to benefit. Otherwise, this issue is of little use - Anatol
  • DDD is such a broad approach that it can be attributed to anything. What common sense suggests is that changeAdvertCost and changeAdvertName clearly redundant methods (since they do not introduce their own logic) - the getAdvert(id) method in the Seller class would look more logical. But the excess should be as small as possible - in order not to disperse the attention of those who will be engaged in this code, and accordingly speed up the development + postpone the moment of collapse. - Goncharov Alexander

1 answer 1

From the point of view of DDD ( blue book , red book ), option No. 2 is more true.

The behavior of the unit must be expressed by commands. Calling the team of the unit - we order him to change his state.

OOP paradigm does not directly correspond to the grammar of the spoken language. We usually write "Seller changes ad". The subject changes the object. But in OOP grammar, objects change their own state in response to external commands. List.addItem (...) - we do not change the list, we send the command to the list: "list, change your status".

What should be the units? (in the context of this issue)

  1. Be a data consistency boundary.

When developing UNITS, there may be a desire to create a structure that can be traversed along deep object graphs, but the purpose of this pattern is different. The book [Evans] states that a single UNIT can contain references to the ROOTS of other UNITS. However, we must keep in mind that this does not place the referenced UNIT, within the boundaries of the UNIT's consistency that refers to it. The link does not generate a single unit. Instead, there are two or more units.

Source: IDDD V. Vernon Von Vernon in his IDDD advises to refer to other aggregates by their identifiers.

  1. Should try to avoid introducing dependencies, including from other aggregates.

According to IDDD, you should try to avoid dependencies on other aggregates, services, repositories. The unit should be as isolated as possible.

Sources:

stackoverflow answer

DDD

IDDD

  • Thank you very much for your answer! The moments that you noted are the most basic. You answered very well, but I will show a little arrogance. I would like to drop a little deeper and more practical. If everything is explained theoretically, then the book will pull. Therefore, I ask, if possible, to make an update to the answer, where to show the structure of the unit on a specific example (described in the next comment). - Andrey K.
  • Problem: The company LLC "Zoo-Agregat" has a network of zoos throughout our country. The peculiarity of these zoos is that in each of those only monkeys and elephants can be present. And they walk on special platforms and they hang sensors that report the coordinates. If possible, give an example of a zoo unit in which we operate with the following data: Sensor, Elephant, its info, Monkey, its info, platform (2D, that is, in flat space, rectangular for simplicity). If anything, then sorry for the audacity, maybe I misdirected there. - Andrey K.
  • Accordingly, it should be possible to read and write all the data. Reading - all data, writing - all data except for sensor data about coordinates. - Andrey K.
  • @AndreyK. Need to start with why you decided that the "Zoo" you have to be a unit? It is rarely justified to make a unit so large. I think you consider the pattern aggregate, more as a technical tool, although in the first place it is a tool for modeling the subject area. And you just need to start with the modeling of your subject area. There is not enough information in your comment to understand how best to model. Besides, it is not entirely clear, you want to understand how to model behavior in entities, or just to describe what entities should be? - Yury Golikov
  • @AndreyK. Can you describe in more detail the subject area of ​​what you need? - Yury Golikov