7 ms·

> It's striking to me how out of touch Martin seems to be with the realities of software engineering in this transcript It was always like that. And Fowler the

> It's striking to me how out of touch Martin seems to be with the realities of software engineering in this transcript It was always like that. And Fowler the same thing with his criticism of anemic domain model. But software-engineering is no exceptions to having a mass of people believing someone without thinking by themselves.

motorest 2y ago
> It was always like that. And Fowler the same thing with his criticism of anemic domain model. What leads you to disagree with the fact that anemic domain models are an anti-pattern? https://martinfowler.com/bliki/AnemicDomainModel.html https://martinfowler.com/bliki/AnemicDomainModel.html I think it's obvious that his critique makes sense if you actually take a moment to try learn and understand what he says and where he comes from. Take a moment to understand what case he makes: it's not object-oriented programming. That's it. See,in a anemic domain model, instead of objects you have DTOs that are fed into functions. That violates basic tenners of OO programming. It's either straight up procedural programming or, if you squint hard enough, functional programming. If you focus on OO as a goal, it's clearly an anti-pattern. His main argument is summarized in the following sentence: > In essence the problem with anemic domain models is that they incur all of the costs of a domain model, without yielding any of the benefits. Do you actually argue against it? Listen, people like Fowler and Uncle Bob advocate for specific styles. This means they have to adopt a rethoric style which focuses on stressing the virtues of a style and underlining the problems solved by the style and created by not following the style. That's perfectly fine. It's also fine if you don't follow something with a religious fervor. If you have a different taste, does it mean anyone who disagrees with you is wrong? What's not cool is criticizing someone out of ignorance and laziness, and talking down on someone or something just because you feel that's how your personal taste is valued.
- overgard 2y ago
  "It's not object oriented programming" is only a good case to make if you think object oriented programming is synonomous with good. I don't think that's true. It's sometimes good, often not good. Why would focusing on OO be a goal? The goal is to write good software that can be easily maintained. Nobody outside of book writers are shipping UML charts
  - rester324 2y ago
    Why would you not focus on writing OO code in an OO language for example? Would you start writing OO code in a functional langugage? No you wouldn't, because it would be pointless. There are programming paradigms for a reason
    - brodo 2y ago
      > Why would you not focus on writing OO code in an OO language for example? Often people do this to deliver higher quality software. Most languages still have some OO features, and people don't use them because they know they lead to bad code. Inheritence (a core OO feature) comes to mind. Most professionals nowadays agree that it should not be used. OO designs are often over-abstracted which makes them hard to understand and hard to change. They lack "locality of behavior". Trivial algorithms look complicated because parts of them are strewn across several classes. This is why more modern langues tend to move away from OOP. My guess is that im the long term, what we will keep from OO is the possibility to associate methods with structs.
    - lmm 2y ago
      > Why would you not focus on writing OO code in an OO language for example? That's circular logic. I wouldn't focus on writing OO code because I know from experience that the result is usually worse. If I had to use a language that was oriented towards writing OO code, I'd still try to limit the damage. > There are programming paradigms for a reason Nah. A lot of them are just accidents of history.
    - wglb 2y ago
      > Why would you not focus on writing OO code in an OO language It should be the best solution to the problem direct whether or not use of OO is best, not the language.
    - throw16180339 2y ago
      > Why would you not focus on writing OO code in an OO language for example? Would you start writing OO code in a functional language? No you wouldn't, because it would be pointless. There are programming paradigms for a reason I'm paid for efficiently solving business problems with software, not using a particular paradigm. If an FP solution is more appropriate and the team can support it, then that's what I'll use.
- valenterry 2y ago
  > 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.

motorest 2y ago

> It was always like that. And Fowler the same thing with his criticism of anemic domain model. What leads you to disagree with the fact that anemic domain models are an anti-pattern? https://martinfowler.com/bliki/AnemicDomainModel.html https://martinfowler.com/bliki/AnemicDomainModel.html I think it's obvious that his critique makes sense if you actually take a moment to try learn and understand what he says and where he comes from. Take a moment to understand what case he makes: it's not object-oriented programming. That's it. See,in a anemic domain model, instead of objects you have DTOs that are fed into functions. That violates basic tenners of OO programming. It's either straight up procedural programming or, if you squint hard enough, functional programming. If you focus on OO as a goal, it's clearly an anti-pattern. His main argument is summarized in the following sentence: > In essence the problem with anemic domain models is that they incur all of the costs of a domain model, without yielding any of the benefits. Do you actually argue against it? Listen, people like Fowler and Uncle Bob advocate for specific styles. This means they have to adopt a rethoric style which focuses on stressing the virtues of a style and underlining the problems solved by the style and created by not following the style. That's perfectly fine. It's also fine if you don't follow something with a religious fervor. If you have a different taste, does it mean anyone who disagrees with you is wrong? What's not cool is criticizing someone out of ignorance and laziness, and talking down on someone or something just because you feel that's how your personal taste is valued.

overgard 2y ago
"It's not object oriented programming" is only a good case to make if you think object oriented programming is synonomous with good. I don't think that's true. It's sometimes good, often not good. Why would focusing on OO be a goal? The goal is to write good software that can be easily maintained. Nobody outside of book writers are shipping UML charts
- rester324 2y ago
  Why would you not focus on writing OO code in an OO language for example? Would you start writing OO code in a functional langugage? No you wouldn't, because it would be pointless. There are programming paradigms for a reason
  - brodo 2y ago
    > Why would you not focus on writing OO code in an OO language for example? Often people do this to deliver higher quality software. Most languages still have some OO features, and people don't use them because they know they lead to bad code. Inheritence (a core OO feature) comes to mind. Most professionals nowadays agree that it should not be used. OO designs are often over-abstracted which makes them hard to understand and hard to change. They lack "locality of behavior". Trivial algorithms look complicated because parts of them are strewn across several classes. This is why more modern langues tend to move away from OOP. My guess is that im the long term, what we will keep from OO is the possibility to associate methods with structs.
  - lmm 2y ago
    > Why would you not focus on writing OO code in an OO language for example? That's circular logic. I wouldn't focus on writing OO code because I know from experience that the result is usually worse. If I had to use a language that was oriented towards writing OO code, I'd still try to limit the damage. > There are programming paradigms for a reason Nah. A lot of them are just accidents of history.
  - wglb 2y ago
    > Why would you not focus on writing OO code in an OO language It should be the best solution to the problem direct whether or not use of OO is best, not the language.
  - throw16180339 2y ago
    > Why would you not focus on writing OO code in an OO language for example? Would you start writing OO code in a functional language? No you wouldn't, because it would be pointless. There are programming paradigms for a reason I'm paid for efficiently solving business problems with software, not using a particular paradigm. If an FP solution is more appropriate and the team can support it, then that's what I'll use.
valenterry 2y ago
> 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.