6 ms·

I agree very much that DDD is an extension of OOP in many ways, but very much disagree that DDD (or OOP) is synonymous with "lots of code". OOP (like any princi

I agree very much that DDD is an extension of OOP in many ways, but very much disagree that DDD (or OOP) is synonymous with "lots of code". OOP (like any principle) is easy to misuse/abuse when doing it for the sake of it, and so personally I'd discourage OOP (and by extension, DDD) for anyone who isn't confident that it fits their model of thinking, nor if they're unaware of the pros and cons... but good OOP (what little of it exists) is very powerful as a way to translate business logic into code. Most non-technical people do not talk about data, and do not think about programs as data transformation, they think about their domain, and they are best served by code that represents their understanding of the business, not some developers decision about how their business is best represented using data. Essentially, I'd describe DDD as high risk, high reward, and so for most businesses, it's not the right decision. However, if you have a talented and experienced team that deeply understand both the business and programming, then DDD is a great opportunity.

dagw 4y ago
I agree very much that DDD is an extension of OOP in many ways May I recommend the video Domain Modeling Made Functional: https://www.youtube.com/watch?v=9QlhkQl0DSw https://www.youtube.com/watch?v=9QlhkQl0DSw and the book on the same topic: https://pragprog.com/titles/swdddf/domain-modeling-made-functional https://pragprog.com/titles/swdddf/domain-modeling-made-func... Scott Wlaschin has been on a "crusade" for years to decouple DDD from OOP and show that doing DDD in a functional language (he uses F# for all his examples) is not only possible, but preferable. He might not change your mind, but it will make you look at DDD from a new angle.
caffeine 4y ago
> they are best served by code that represents their understanding of the business Genuinely curious why you think this is? To me it seems a massive leap? Trying to steel-man this, if: 1. The people who know best about the domain are not technical and don’t know algorithm thinking 2. The technical people are not capable of understanding the domain enough to separately discuss what the code does and how it does it This is basically the consulting scenario, which is where DDD came from (?) Then it would make sense - when the team leaves and the next guy comes in with no clue how it works, he can read it out to the domain expert who will roughly understand what it’s doing. On the good teams I’ve seen, the domain experts and the people coding are the usually same people, the “domain vocabulary” is CS, and the team is looking for maximum leverage (trying to do with 10 ppl what others do with 100 people). So it’s quite a different scenario than 100 ThoughtWorkers getting dropped into some vertical they know nothing about and being expected to model a bunch of existing business processes.
- phphphphp 4y ago
  Everybody within a business should be using the same language and concepts when thinking about the business, because it's important for effective communication: daylight between what people are thinking about is where problems creep in. The role of any people of any discipline within a business is to use their expertise to shape _how_ they think about the shared _what_. Code is just one tool (of many) that a business will use to achieve its goals. There's a mythology in a lot of businesses around the genius of technologists because we understand the complex system that we built that everybody else in the business is too dumb to understand, but in reality it's because technologists are uniquely permitted to decide they're better than everyone else and diverge from the shared thinking because it's easier than reconciling business concepts with technology -- which is where the actual hard part of software engineering is! If you walk into any business that has been around for a few years and has allowed their technology team to do whatever they want, you'll probably find a completely incomprehensible system that the business hates because it has diverged so far from how they think and what they want that they can't effectively do their jobs. People come and go, the only constant in a business is the business. An example that comes to mind is a business that has customers who pay for membership, and so they're called "members" within the business. However, the development team decided they knew better and implemented "user" accounts which can have a "subscription". Then, later, the business decided to introduce a subscriptions product... and so the problems began.

dagw 4y ago

I agree very much that DDD is an extension of OOP in many ways May I recommend the video Domain Modeling Made Functional: https://www.youtube.com/watch?v=9QlhkQl0DSw https://www.youtube.com/watch?v=9QlhkQl0DSw and the book on the same topic: https://pragprog.com/titles/swdddf/domain-modeling-made-functional https://pragprog.com/titles/swdddf/domain-modeling-made-func... Scott Wlaschin has been on a "crusade" for years to decouple DDD from OOP and show that doing DDD in a functional language (he uses F# for all his examples) is not only possible, but preferable. He might not change your mind, but it will make you look at DDD from a new angle.

caffeine 4y ago

> they are best served by code that represents their understanding of the business Genuinely curious why you think this is? To me it seems a massive leap? Trying to steel-man this, if: 1. The people who know best about the domain are not technical and don’t know algorithm thinking 2. The technical people are not capable of understanding the domain enough to separately discuss what the code does and how it does it This is basically the consulting scenario, which is where DDD came from (?) Then it would make sense - when the team leaves and the next guy comes in with no clue how it works, he can read it out to the domain expert who will roughly understand what it’s doing. On the good teams I’ve seen, the domain experts and the people coding are the usually same people, the “domain vocabulary” is CS, and the team is looking for maximum leverage (trying to do with 10 ppl what others do with 100 people). So it’s quite a different scenario than 100 ThoughtWorkers getting dropped into some vertical they know nothing about and being expected to model a bunch of existing business processes.

phphphphp 4y ago
Everybody within a business should be using the same language and concepts when thinking about the business, because it's important for effective communication: daylight between what people are thinking about is where problems creep in. The role of any people of any discipline within a business is to use their expertise to shape _how_ they think about the shared _what_. Code is just one tool (of many) that a business will use to achieve its goals. There's a mythology in a lot of businesses around the genius of technologists because we understand the complex system that we built that everybody else in the business is too dumb to understand, but in reality it's because technologists are uniquely permitted to decide they're better than everyone else and diverge from the shared thinking because it's easier than reconciling business concepts with technology -- which is where the actual hard part of software engineering is! If you walk into any business that has been around for a few years and has allowed their technology team to do whatever they want, you'll probably find a completely incomprehensible system that the business hates because it has diverged so far from how they think and what they want that they can't effectively do their jobs. People come and go, the only constant in a business is the business. An example that comes to mind is a business that has customers who pay for membership, and so they're called "members" within the business. However, the development team decided they knew better and implemented "user" accounts which can have a "subscription". Then, later, the business decided to introduce a subscriptions product... and so the problems began.