5 ms·

> it's not object-oriented programming. That's it. Yes, exactly. And this "classical" object-oriented programming is an anti-pattern itself. (That being said,

> it's not object-oriented programming. That's it. Yes, exactly. And this "classical" object-oriented programming is an anti-pattern itself. (That being said, OOP is not well defined. And, for example, I have nothing against putting related data structures and functionality into the same namespace. But that's not what OOP means to him here)

valenterry 2y ago
I'll reply here with a very quick example why the anemic domain model is superior in general, no matter if you do OOP or anything else. You used the example of an "order" yourself, so I'll built upon it. I would never combine functionality to update an order with the data and structure of the an order. The reason is simple: the business constraints don't always live inside the order. Here's an example why such an approach inevitably must fail: if the business says that orders can only be made until 10000 items have been ordered in a month, then you cannot model that constraint inside of the order class. You must move it outside - to the entity that knows about all the orders in the system. That would be the OrderRepository or however you want to call it. Remember, here is what you said in your other post: > Your Order class has a collection of Product items, but you can update an order, cancel a order, repeat an order, etc. This behavior should be member functions. So your Order should have a repeat function? But how can the order know if it can be repeated? It might violate the max-monthly-items constraint. The only way for the Order to do it is to hold a reference to the OrderRepository. And this is a big problem. You have now entangled the concept of an OrderRepository and of an Order. In fact, Orders could totally live without an OrderRepository alltogether, for example when you build an OrderSimulation where no orders are actually being executed/persisted. But to do so, now you have this OrderRepository, even if you don't need it. The rule of the thumb is: if the business says "we don't need feature A anymore, remove it" then you should be able to remove that feature from the code without touching any unrelated feature. If you now remove the OrderRepository and cause a bug in the Order class due to your code changes, the business will probably wonder how that could be, because while the OrderRepository cannot exist without Orders, Orders can exist without an OrderRepository. And if that seems a bit unrealistic, think of users: A user can easily exist without a UserRepository, but not the other way around. That makes clear, that you the rich domain model is an unsuitable and generally suboptimal solution to modeling the domain of a business. The anemic domain model on the other hand matches it perfectly. And one more thing: even natural language disagrees with the rich domain model. Does an order repeat itself? No! An order is repeated and that is, it is repeated by something or someone. This alone makes clear that there is an entity beyond the Order that is responsible for such action. And again, the anemic domain model is a great solution for expressing this in code. But if you disagree, I'd like you to explain what you believe the disadvantages of the anemic domain model are.
- Kinrany 2y ago
  Links to any existing articles on this topic would be greatly appreciated.
  - valenterry 2y ago
    This is the original article from Fowler: https://martinfowler.com/bliki/AnemicDomainModel.html https://martinfowler.com/bliki/AnemicDomainModel.html By searching for that term, you'll easily find lots of other takes on the matter.
    - Kinrany 2y ago
      > I'll reply here with a very quick example why the anemic domain model is superior in general, no matter if you do OOP or anything else. I can search for it of course but results that aren't about OOP purism appear to be rare.
  - mrkeen 2y ago
    I highly recommend a video if you don't mind the format: https://youtu.be/zHiWqnTWsn4?t=3134 https://youtu.be/zHiWqnTWsn4?t=3134 The slide at 52:14 is on the SOLID principles, the first one is on SRP which gives pretty understandable advice about whether Order should have behaviours.
- samiv 2y ago
  You made a great example here and I absolutely agree with you. In fact I find this type of accidental / unneeded coupling is the number one cause of problems, bugs and limitations of re-use and thus development velocity in any software product. Concepts where a single way dependency is turned into a cycling dependency are really hard to evolve, maintain, test and understand. In fact I'd go as far as to say that as a general rule of thumb if you have a situation where your class A depends on class B that depends on class A you've made a big doo doo and you should really seriously re-consider your design. (Adjacent to this rule is that classes that exist in the same level of of the software hierarchy and are thus siblings should also not know about each other). In fact when you structure your code so that the dependencies only go one way you end up with a neat lasagna code base and everything can easily slotted in. (Combined with this a secondary feature which is to eliminate all jumps upwards in the stack, i.e. callbacks)

valenterry 2y ago

I'll reply here with a very quick example why the anemic domain model is superior in general, no matter if you do OOP or anything else. You used the example of an "order" yourself, so I'll built upon it. I would never combine functionality to update an order with the data and structure of the an order. The reason is simple: the business constraints don't always live inside the order. Here's an example why such an approach inevitably must fail: if the business says that orders can only be made until 10000 items have been ordered in a month, then you cannot model that constraint inside of the order class. You must move it outside - to the entity that knows about all the orders in the system. That would be the OrderRepository or however you want to call it. Remember, here is what you said in your other post: > Your Order class has a collection of Product items, but you can update an order, cancel a order, repeat an order, etc. This behavior should be member functions. So your Order should have a repeat function? But how can the order know if it can be repeated? It might violate the max-monthly-items constraint. The only way for the Order to do it is to hold a reference to the OrderRepository. And this is a big problem. You have now entangled the concept of an OrderRepository and of an Order. In fact, Orders could totally live without an OrderRepository alltogether, for example when you build an OrderSimulation where no orders are actually being executed/persisted. But to do so, now you have this OrderRepository, even if you don't need it. The rule of the thumb is: if the business says "we don't need feature A anymore, remove it" then you should be able to remove that feature from the code without touching any unrelated feature. If you now remove the OrderRepository and cause a bug in the Order class due to your code changes, the business will probably wonder how that could be, because while the OrderRepository cannot exist without Orders, Orders can exist without an OrderRepository. And if that seems a bit unrealistic, think of users: A user can easily exist without a UserRepository, but not the other way around. That makes clear, that you the rich domain model is an unsuitable and generally suboptimal solution to modeling the domain of a business. The anemic domain model on the other hand matches it perfectly. And one more thing: even natural language disagrees with the rich domain model. Does an order repeat itself? No! An order is repeated and that is, it is repeated by something or someone. This alone makes clear that there is an entity beyond the Order that is responsible for such action. And again, the anemic domain model is a great solution for expressing this in code. But if you disagree, I'd like you to explain what you believe the disadvantages of the anemic domain model are.

Kinrany 2y ago
Links to any existing articles on this topic would be greatly appreciated.
- valenterry 2y ago
  This is the original article from Fowler: https://martinfowler.com/bliki/AnemicDomainModel.html https://martinfowler.com/bliki/AnemicDomainModel.html By searching for that term, you'll easily find lots of other takes on the matter.
  - Kinrany 2y ago
    > I'll reply here with a very quick example why the anemic domain model is superior in general, no matter if you do OOP or anything else. I can search for it of course but results that aren't about OOP purism appear to be rare.
- mrkeen 2y ago
  I highly recommend a video if you don't mind the format: https://youtu.be/zHiWqnTWsn4?t=3134 https://youtu.be/zHiWqnTWsn4?t=3134 The slide at 52:14 is on the SOLID principles, the first one is on SRP which gives pretty understandable advice about whether Order should have behaviours.
samiv 2y ago
You made a great example here and I absolutely agree with you. In fact I find this type of accidental / unneeded coupling is the number one cause of problems, bugs and limitations of re-use and thus development velocity in any software product. Concepts where a single way dependency is turned into a cycling dependency are really hard to evolve, maintain, test and understand. In fact I'd go as far as to say that as a general rule of thumb if you have a situation where your class A depends on class B that depends on class A you've made a big doo doo and you should really seriously re-consider your design. (Adjacent to this rule is that classes that exist in the same level of of the software hierarchy and are thus siblings should also not know about each other). In fact when you structure your code so that the dependencies only go one way you end up with a neat lasagna code base and everything can easily slotted in. (Combined with this a secondary feature which is to eliminate all jumps upwards in the stack, i.e. callbacks)