4 ms·

It’s a shame that Domain Driven Design and Data Driven Design have the same acronym, while being basically polar opposites (some people call the latter Data Ori

It’s a shame that Domain Driven Design and Data Driven Design have the same acronym, while being basically polar opposites (some people call the latter Data Oriented Design for this reason). To me, Domain-Driven is sort of an extension of Object-Oriented fundamentalism that used to reign, especially in the Java world. You make a class or a micro-service for every concept in your world. It’s a great way for a huge team of programmers to write a massive amount of code that doesn’t do very much (there are always exceptions, of course!) - with elaborate contortions to model and name everything just right. You might wind up needing things like Dependency Injection frameworks, mocking frameworks for tests, etc. Data-Driven is the idea of leaning in to the fact that fundamentally, your software is a program, running in computers. It is going to turn some input into some output. You design along the axis of what data you need, how it is represented, where it needs to go, what transformations need to be applied, what output needs to be produced, and what needs to be stored. It tends to look more like functional programming, although you can certainly also apply mutating transformations, usually for efficiency. IMHO, the latter is a great way for smaller teams to produce modest amounts of code that accomplishes a great deal.

hsn915 4y ago
> It’s a great way for a huge team of programmers to write a massive amount of code that doesn’t do very much Yea. I often hear the excuse "it's for many lines of code written by large teams" but what's often ignored is that all this code is not doing much actually. Data Oriented Design is a breath of fresh air.
phphphphp 4y ago
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.
eweise 4y ago
I never found domain driven design to be an extension of object oriented design or microservices. Its mainly a way of organizing your code so it doesn't turn into a big ball of mud at some point.
karmakaze 4y ago
DDD seeming as an extension to OOP is no co-incidence. An intro page[0] for author Eric Evans shows: > Eric Evans is the author of “Domain-Driven Design: Tackling Complexity in Software,” Addison-Wesley 2004. > Since the early 1990s, he has worked on many projects developing large business systems with objects with many different approaches and many different outcomes. The book is a synthesis of that experience. It presents a system of modeling and design techniques that successful teams have used to align complex software systems with business needs and to keep projects agile as systems grow large. [0] https://nofluffjuststuff.com/conference/speaker/eric_evans https://nofluffjuststuff.com/conference/speaker/eric_evans
falcolas 4y ago
> It’s a great way for a huge team of programmers to write a massive amount of code that doesn’t do very much (there are always exceptions, of course!) - with elaborate contortions to model and name everything just right. You might wind up needing things like Dependency Injection frameworks, mocking frameworks for tests, etc. Damn. Talk about calling out my team. Like, perfectly describing our current project. And, as expected, even correct unit tests will randomly fail. Sigh.
zmgsabst 4y ago
I’m not sure I understand this comment — aren’t the two different things? DDD is a business-to-software paradigm to decide what software to build, defining the relevant terms — what the data is, how it’s used, etc. DOD is a framework for turning that map of relationships into a technical implementation, as you can see from the inputs to DOD being the outputs of DDD. I see it as frontend (DDD) and backend (DOD) in a compiler chain of business needs to technical system.
nchi3 4y ago
I don't agree at all. They're very orthogonal concepts, and DDD has very little to do with OO. For an example, see Domain Modeling Made Functional. Yes, if you do DDD in Java, you should probably follow OO principles. If you end up with a lot of classes "that do nothing", you've probably done something wrong along the way or you've applied it to something very simple where it didn't make sense to do so.

hsn915 4y ago

> It’s a great way for a huge team of programmers to write a massive amount of code that doesn’t do very much Yea. I often hear the excuse "it's for many lines of code written by large teams" but what's often ignored is that all this code is not doing much actually. Data Oriented Design is a breath of fresh air.

phphphphp 4y ago

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.

eweise 4y ago

I never found domain driven design to be an extension of object oriented design or microservices. Its mainly a way of organizing your code so it doesn't turn into a big ball of mud at some point.

karmakaze 4y ago

DDD seeming as an extension to OOP is no co-incidence. An intro page[0] for author Eric Evans shows: > Eric Evans is the author of “Domain-Driven Design: Tackling Complexity in Software,” Addison-Wesley 2004. > Since the early 1990s, he has worked on many projects developing large business systems with objects with many different approaches and many different outcomes. The book is a synthesis of that experience. It presents a system of modeling and design techniques that successful teams have used to align complex software systems with business needs and to keep projects agile as systems grow large. [0] https://nofluffjuststuff.com/conference/speaker/eric_evans https://nofluffjuststuff.com/conference/speaker/eric_evans

falcolas 4y ago

> It’s a great way for a huge team of programmers to write a massive amount of code that doesn’t do very much (there are always exceptions, of course!) - with elaborate contortions to model and name everything just right. You might wind up needing things like Dependency Injection frameworks, mocking frameworks for tests, etc. Damn. Talk about calling out my team. Like, perfectly describing our current project. And, as expected, even correct unit tests will randomly fail. Sigh.

zmgsabst 4y ago

I’m not sure I understand this comment — aren’t the two different things? DDD is a business-to-software paradigm to decide what software to build, defining the relevant terms — what the data is, how it’s used, etc. DOD is a framework for turning that map of relationships into a technical implementation, as you can see from the inputs to DOD being the outputs of DDD. I see it as frontend (DDD) and backend (DOD) in a compiler chain of business needs to technical system.

nchi3 4y ago

I don't agree at all. They're very orthogonal concepts, and DDD has very little to do with OO. For an example, see Domain Modeling Made Functional. Yes, if you do DDD in Java, you should probably follow OO principles. If you end up with a lot of classes "that do nothing", you've probably done something wrong along the way or you've applied it to something very simple where it didn't make sense to do so.