DDD Is Overrated(tilkov.com)
tilkov.com
DDD Is Overrated
https://tilkov.com/post/2021/03/01/ddd-is-overrated/
96 comments
You need to understand the context that birthed DDD. It was a reaction to the model of building business logic into UI event handlers which was pushed hard at the time by the Visual Basic (and java equivalent) crowd in businesses.
Originally Fowler documented the domain model in PoEAA, then Evans took the idea and ran with it.
I agree that the book hasn't aged well: like the GoF book it's a slog to read. Evans isn't Fowler.
Originally Fowler documented the domain model in PoEAA, then Evans took the idea and ran with it.
I agree that the book hasn't aged well: like the GoF book it's a slog to read. Evans isn't Fowler.
I don't think that history is right. Martin was talking about Eric's work and crediting him long before Eric's book came out. I saw Martin give a talk just before PoEAA came out and he was telling people to wait for Eric's book to get the richest take on domain modeling.
DDD was born from Eric's roots in Smalltalk development. When Smalltalk got supplanted by Java there was a strong desire to find ways of building Java systems that could recover at least some of that development style, such as domain modeling, despite the technology being less flexible. At the time it had sort of the feel of 'preserving what we can of civilization after the apocalypse'.
DDD wasn't the only thing that emerged from this. Other Smalltalk programmers became influential programming teachers in the post-Smalltalk world (Fowler, Beck, Cunningham). Eric was probably the last of these to emerge because he spent years working on his book. (It's been years since I've read it but my impression was always that it was unusually well written. It's true that you have to read it as a book to really get it, which is kind of a lot to ask nowadays.)
DDD was born from Eric's roots in Smalltalk development. When Smalltalk got supplanted by Java there was a strong desire to find ways of building Java systems that could recover at least some of that development style, such as domain modeling, despite the technology being less flexible. At the time it had sort of the feel of 'preserving what we can of civilization after the apocalypse'.
DDD wasn't the only thing that emerged from this. Other Smalltalk programmers became influential programming teachers in the post-Smalltalk world (Fowler, Beck, Cunningham). Eric was probably the last of these to emerge because he spent years working on his book. (It's been years since I've read it but my impression was always that it was unusually well written. It's true that you have to read it as a book to really get it, which is kind of a lot to ask nowadays.)
Martin's books formalised learnings of others - including those from the Smalltalk community - and PoEAA acts like a good map to the works of information systems.
When I say that "Eric took that idea and ran with it", I mean that Eric went into a lot of detail on the Domain Model (and wrote the definitive book on it). Given the way that Fowler (and Thought Works) work I wouldn't be surprised if Eric was one of the main sources.
Both books had a great impact on me, and they're both on the reading list I give to developers I'm mentoring.
Properly applied DDD is extremely effective, just using Bounded Contexts is extremely valuable (i.e. taking a high level view of your enterprise, putting logical boundaries in place and accepting different abstractions in different contexts).
When I say that "Eric took that idea and ran with it", I mean that Eric went into a lot of detail on the Domain Model (and wrote the definitive book on it). Given the way that Fowler (and Thought Works) work I wouldn't be surprised if Eric was one of the main sources.
Both books had a great impact on me, and they're both on the reading list I give to developers I'm mentoring.
Properly applied DDD is extremely effective, just using Bounded Contexts is extremely valuable (i.e. taking a high level view of your enterprise, putting logical boundaries in place and accepting different abstractions in different contexts).
> just using Bounded Contexts is extremely valuable
Eric would be happy to hear that. I think he felt that the later chapters of the book, on strategic design, got insufficient attention. Ubiquitous language only applies within a bounded context!
Eric would be happy to hear that. I think he felt that the later chapters of the book, on strategic design, got insufficient attention. Ubiquitous language only applies within a bounded context!
What is GoF book?
"Design Patterns: Elements of Reusable Object-Oriented Software". also called the Gang-of-Four or GoF book for the four authors.
Thanks!
I'm a big fan of Carlo Pescio's musings. Thanks for the link!
One thing I heard recently, that I found pretty true when role-playing in my mind, is that most of the design methodologies get like... 90% of their value from forcing _a_ methodology onto people.
The barebones "top-down"/"bottom-up" strategies most of us start up with is basically no good at forcing us to plan things out. But other strategies cause design errors to bubble up more quickly, so we can fix them, ship stuff that's right the first time etc.
Anyways I guess I just feel like you can totally mix-and-match design methodologies to your problem space, so long as you're actually applying it seriously enough (and have some agreement with stakeholders about it). But I do feel like too much discussion on these topics focus on failure cases and "false practice", and don't really end with actionable advice.
The barebones "top-down"/"bottom-up" strategies most of us start up with is basically no good at forcing us to plan things out. But other strategies cause design errors to bubble up more quickly, so we can fix them, ship stuff that's right the first time etc.
Anyways I guess I just feel like you can totally mix-and-match design methodologies to your problem space, so long as you're actually applying it seriously enough (and have some agreement with stakeholders about it). But I do feel like too much discussion on these topics focus on failure cases and "false practice", and don't really end with actionable advice.
See the paper A Rational Design Process: How and Why to Fake it by David Parnas for the origins of the idea. - https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei...
I have read similar thoughts on psychology. Makes sense to me.
Maybe update the title to "Domain Driven Design is Overrated", because this article has nothing to do with the Data Display Debugger.
Nor with Documentation Driven Development.
Something tells me that in 2021 a lot more people will identify DDD to mean Domain-Driven Design than the concept that you mentioned
I was literally introduced to that term with this article while I've been using ddd off and on for 20 years
Reading wikipedia it looks like one of those trivially stupidly obvious concepts wrapped in overly wordy academic terminology where they invent imaginary distinctions that have no differences in lived reality.
Like this from wikipedia: "An individual bounded context leaves some problems in the absence of a global view. The context of other models may still be vague and in flux.
People on other teams won't be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other."
I mean holy hell, did a markov chain write that?
Let me translate: "yo, some specs are more locked down than others so try to make the code more flexible for the parts that are likely to change" that's it.
In my experience people that wrap simple stuff in academic potpourri get absolutely nothing done and generate really defective bloated software at very high cost because their code is written in the same way: simple things done in confusing and incomprehensible ways.
It's as if someone covered something as dumb as rocks with the maximum amount of bullshit possible where you can still just barely translate it to comprehensible English.
I'm surprised there's no set theory equations in that wikipedia page, maybe a bit of lambda calculus. We should get on that.
In fact, let's make a tool where you define your contexts in Haskell and then run it over your code like a linter to generate GraphML files so someone can run it through graphviz and print it out to put it on their wall to have in the background during their stand-ups so they can make themselves look super professional. Who cares if your deadlines slipped another month, you're clearly an authority!
Other industries, like hairbraiding require certificates and licenses to protect their jobs. In software, instead, apparently, some people ornately festoon simple things with fancy language and hide it behind acronym soup.
Go work on harder problems, seriously
Reading wikipedia it looks like one of those trivially stupidly obvious concepts wrapped in overly wordy academic terminology where they invent imaginary distinctions that have no differences in lived reality.
Like this from wikipedia: "An individual bounded context leaves some problems in the absence of a global view. The context of other models may still be vague and in flux.
People on other teams won't be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other."
I mean holy hell, did a markov chain write that?
Let me translate: "yo, some specs are more locked down than others so try to make the code more flexible for the parts that are likely to change" that's it.
In my experience people that wrap simple stuff in academic potpourri get absolutely nothing done and generate really defective bloated software at very high cost because their code is written in the same way: simple things done in confusing and incomprehensible ways.
It's as if someone covered something as dumb as rocks with the maximum amount of bullshit possible where you can still just barely translate it to comprehensible English.
I'm surprised there's no set theory equations in that wikipedia page, maybe a bit of lambda calculus. We should get on that.
In fact, let's make a tool where you define your contexts in Haskell and then run it over your code like a linter to generate GraphML files so someone can run it through graphviz and print it out to put it on their wall to have in the background during their stand-ups so they can make themselves look super professional. Who cares if your deadlines slipped another month, you're clearly an authority!
Other industries, like hairbraiding require certificates and licenses to protect their jobs. In software, instead, apparently, some people ornately festoon simple things with fancy language and hide it behind acronym soup.
Go work on harder problems, seriously
Agreed, sounds like they are trying to say that two people in different settings can make changes without understanding the reasons. It could also be summed up with, "go talk to each other"
I summarize all those theories as "how to be a human". There's all these tech business books with titles like "Lean Innovation" and they must be written for people without the crudest socialization skills.
It has flow charts, diagrams, tabular statistics, you know, to conclude groundbreaking things like "talking to at least one customer before releasing a product is a smart idea" or "don't waste time on unimportant things"
I'm like "Dude, did you just want a section for your CV that says 'Recent Publications'?"
It has flow charts, diagrams, tabular statistics, you know, to conclude groundbreaking things like "talking to at least one customer before releasing a product is a smart idea" or "don't waste time on unimportant things"
I'm like "Dude, did you just want a section for your CV that says 'Recent Publications'?"
I encourage you to read more.. Your take on the wikipedia article reads as as you had your decision made up beforehand. The words he uses, which you think are too elaborate, have specific definitions within the context of the book. Your 'summary' missed the mark completely
Of course they do. That's part of the theater.
Some things are genuinely complicated and others are intentionally so.
This is clearly something that is complicated by choice, not by necessity.
All that "complicated by choice" leads to is fundamentalism and orthodoxy. People worry about whether their code matches the new sacred scripture over whether it works and then they shoehorn things into the form that don't belong there.
They bake meaning onto code that's way out of scope of the project. It's like programmers Gematria.
I've seen these all-knowing preachers write broken code and leave unmaintainable dumpster fires in their wake my whole career. Giant cathedral messes that barely do anything that all the customers complain about with endless academic blabbering everywhere and very little to show for it.
It's a "type", more rare than others, but they're out there.
If the results are better and the systems work sign me up. But if it's just another church of code with mere ceremony and internal logic, then yeah, have fun at mass.
Some things are genuinely complicated and others are intentionally so.
This is clearly something that is complicated by choice, not by necessity.
All that "complicated by choice" leads to is fundamentalism and orthodoxy. People worry about whether their code matches the new sacred scripture over whether it works and then they shoehorn things into the form that don't belong there.
They bake meaning onto code that's way out of scope of the project. It's like programmers Gematria.
I've seen these all-knowing preachers write broken code and leave unmaintainable dumpster fires in their wake my whole career. Giant cathedral messes that barely do anything that all the customers complain about with endless academic blabbering everywhere and very little to show for it.
It's a "type", more rare than others, but they're out there.
If the results are better and the systems work sign me up. But if it's just another church of code with mere ceremony and internal logic, then yeah, have fun at mass.
I think the problem is that these methods and authors are heavily incentivized to make a name for themselves and a framework which can become a business somehow.
There's a serious lack of scientific rigour in these areas, and from my experience, it's heavily driven by popularity. Besides, i still don't see a reason why you could not explain things in simpler terms.
If you get smart people together who can communicate well, think for themselves and don't stand in their way, it will always outperform any method. But this is so painfully obvious, that no one will pay you to say that. And there's really no cookie cutter recipe to achieve that, anyone who tells you otherwise, probably has something to sell.
There's a serious lack of scientific rigour in these areas, and from my experience, it's heavily driven by popularity. Besides, i still don't see a reason why you could not explain things in simpler terms.
If you get smart people together who can communicate well, think for themselves and don't stand in their way, it will always outperform any method. But this is so painfully obvious, that no one will pay you to say that. And there's really no cookie cutter recipe to achieve that, anyone who tells you otherwise, probably has something to sell.
Your comment is a little funny because Domain-Driven Design is a concept, whereas DDD is an actual software that has existed for decades (a GDB front-end)....
Something tells me that even more people would identify Domain-Driven Design as Domain-Driven Design.
"man ddd" would disagree
speaking of which, ddd is the only application I have installed that relies on motif...
speaking of which, ddd is the only application I have installed that relies on motif...
Wow, Motif. Speaking of overrated... I had mostly blocked it out of my head.
You’re probably right, but it’s still better to spell it out in the title when a good percentage of readers will either be unfamiliar or think of something else.
Wow, that's ancient, the built in graphic plotting feature seems nice though https://www.gnu.org/software/ddd/
I was thinking of the debugger too. I was also surprised to see it described as “overrated” since it’s ratings have never been that good.
That buggy thing is also probably overrated. I'm just not sure how people rate it.
[deleted]
I thought it meant Data Driven Design.....
I was thinking of a fully digital audio recording, digital mixing, and digital mastering. :-)
https://en.wikipedia.org/wiki/SPARS_code
https://en.wikipedia.org/wiki/SPARS_code
If anything, i find that DDD is underrated and underused. But i can totally imagine projects where it goes completely over the top, like anything (frameworks, patterns, microservices, Redux -oh god Redux-, whatever)
Happened the exact same thing with agility when it became Agile™
Sounds like the difference between agile and Agile. It helps to understand the domain when you're architecting a solution, but I didn't realise there was an extended nomenclature around it. I thought it was just a conceptual phrase.
[deleted]
Author talks about how DDD is overrated and gives a couple of arguments about nomenclature.
The real issue seems to be in plain sight in the article:
> But I’m annoyed by the fact that recently, it seems that any time somebody talks about how to architect system or service boundaries, or even just mentions non-technical design, everybody feels compelled to bring in the DDD experts
That's the issue, their own experience has been terrible but I don't see any specifics about why domain driven design is terrible. Provide an example. Go through the rigor of your arguments. Show us some code, something concrete, tell us a story about how it was painful to them and what was the impact - whatever is needed to make a strong argument.
The problem with articles like this is people read up on it, make their mind, and now you have a sloth of people converted to "Anti-DDD religion" will become painful to deal with at work because they read up some HN article about how DDD is overrated. It gets stuck in their minds like cereal in an empty milk bowl.
I expect more from the author after saying "There, I said it." Totally ok to be anti-DDD, would love to hear more though.
The real issue seems to be in plain sight in the article:
> But I’m annoyed by the fact that recently, it seems that any time somebody talks about how to architect system or service boundaries, or even just mentions non-technical design, everybody feels compelled to bring in the DDD experts
That's the issue, their own experience has been terrible but I don't see any specifics about why domain driven design is terrible. Provide an example. Go through the rigor of your arguments. Show us some code, something concrete, tell us a story about how it was painful to them and what was the impact - whatever is needed to make a strong argument.
The problem with articles like this is people read up on it, make their mind, and now you have a sloth of people converted to "Anti-DDD religion" will become painful to deal with at work because they read up some HN article about how DDD is overrated. It gets stuck in their minds like cereal in an empty milk bowl.
I expect more from the author after saying "There, I said it." Totally ok to be anti-DDD, would love to hear more though.
These articles are pretty much impossible to disagree with, because they follow the same pattern.
Every tool, concept, or technology, that aims to address a common need, will eventually reach the point in their adoption curve where an author publishes a hot take.
§1 Clickbait title
§2 Tool X is popular. I'm a fan. Tool X is useful.
§3 It annoys me that everybody(1) treats it as the golden hammer. A single tool is not enough.
§4 There are other tools. We can even make more tools. The best Tool X users use many other tools. You can't shoehorn all problems into Tool X.
§5 Conclusion: Not all things require Tool X.
(1) The term "Everybody" is used, because the author doesn't want to name the individuals or group that caused the annoyance.
It is definitely a pattern because if you’ve been around tech, you’ve read numerous of these articles. I doubt they achieve their goal. I think we need ways to help people avoid golden hammers, without merely pointing at the hammer.
Interestingly, Eric Evans’ work includes heuristics on when not to use DDD, and a call to action to find many more patterns than the ones he lists :-)
Every tool, concept, or technology, that aims to address a common need, will eventually reach the point in their adoption curve where an author publishes a hot take.
§1 Clickbait title
§2 Tool X is popular. I'm a fan. Tool X is useful.
§3 It annoys me that everybody(1) treats it as the golden hammer. A single tool is not enough.
§4 There are other tools. We can even make more tools. The best Tool X users use many other tools. You can't shoehorn all problems into Tool X.
§5 Conclusion: Not all things require Tool X.
(1) The term "Everybody" is used, because the author doesn't want to name the individuals or group that caused the annoyance.
It is definitely a pattern because if you’ve been around tech, you’ve read numerous of these articles. I doubt they achieve their goal. I think we need ways to help people avoid golden hammers, without merely pointing at the hammer.
Interestingly, Eric Evans’ work includes heuristics on when not to use DDD, and a call to action to find many more patterns than the ones he lists :-)
I’ve never explicitly used DDD, but I am convinced there is great value in having an obvious abstraction barrier between a domain core and your application and UI layer. It will allow you to pivot the UX quickly without compromising your core idea.
However, I’m not entirely convinced this needs to be encoded in tech very rigidly. Especially not for starting projects.
Just make sure the vision in in your head is clear and clearly communicated to the entire team. As long as you know what you’re building ‘conceptually’ the chance of your code base becoming a mess is way less likely.
With every line of code you need to know/feel either ‘this is core to our product/domain’ or ‘this might change in a year or so’.
All the DDD/solid/kiss/services whatever paradigms are secondary to having a clear tech and product vision.
However, I’m not entirely convinced this needs to be encoded in tech very rigidly. Especially not for starting projects.
Just make sure the vision in in your head is clear and clearly communicated to the entire team. As long as you know what you’re building ‘conceptually’ the chance of your code base becoming a mess is way less likely.
With every line of code you need to know/feel either ‘this is core to our product/domain’ or ‘this might change in a year or so’.
All the DDD/solid/kiss/services whatever paradigms are secondary to having a clear tech and product vision.
I think this article skips the most important aspect of DDD.
Reducing Complexity.
If you’re building simple systems, you don’t need DDD and Evans has always been clear about that.
But when you have a complex system, using DDD to “pull it apart” is highly effective.
What you build from the parts is subject to that rule as well. If you end up with ten boundaries and some of them are simple, use simple tools.
DDD isn’t a religion. It’s meant to get architects to stop designing monoliths that we know have costly lifespans.
It’s also meant to get us modeling with our business partners with tools like Event Storming and truly understanding strategic opportunities.
DDD isn’t just about root aggregates and value objects.
It’s a communication tool and a pretty damn good one.
Reducing Complexity.
If you’re building simple systems, you don’t need DDD and Evans has always been clear about that.
But when you have a complex system, using DDD to “pull it apart” is highly effective.
What you build from the parts is subject to that rule as well. If you end up with ten boundaries and some of them are simple, use simple tools.
DDD isn’t a religion. It’s meant to get architects to stop designing monoliths that we know have costly lifespans.
It’s also meant to get us modeling with our business partners with tools like Event Storming and truly understanding strategic opportunities.
DDD isn’t just about root aggregates and value objects.
It’s a communication tool and a pretty damn good one.
On the other hand, "Documentation Driven Design" is definitely underrated and an excellent way to end up with a very nice API.
> definitely underrated
Good documentation is under-rated; not sure about designing via the documentation.
> excellent way to end up with a very nice API.
My experience suggests otherwise. I've found that both the code and the documentation "write themselves" at different points of development, progressing logically until they hit some snag or question-mark, with each of them effecting the other side in somewhat unexpected ways - so that working on just one side first is not the right thing to do.
Good documentation is under-rated; not sure about designing via the documentation.
> excellent way to end up with a very nice API.
My experience suggests otherwise. I've found that both the code and the documentation "write themselves" at different points of development, progressing logically until they hit some snag or question-mark, with each of them effecting the other side in somewhat unexpected ways - so that working on just one side first is not the right thing to do.
Sure you might not be able to write 100% of the documentation in one go and then the code, but AFAIK that's neither the goal or the intention of DDD, it's more like "document a bit, write a bit, repeat".
The way I do it is first write a draft of the documentation, of how I want the API to look like. Then check if that basic code is possible (which I can predict most of the times based on experience), then write some more docs or methods. When writing a lib I normally already know where I want to use it, so I can put example snippets from how I want to use it as the documentation first and then try to implement those methods.
Examples of libraries I've written mostly this way:
- https://github.com/franciscop/brownies
- https://github.com/franciscop/files
- https://github.com/franciscop/backblaze
The way I do it is first write a draft of the documentation, of how I want the API to look like. Then check if that basic code is possible (which I can predict most of the times based on experience), then write some more docs or methods. When writing a lib I normally already know where I want to use it, so I can put example snippets from how I want to use it as the documentation first and then try to implement those methods.
Examples of libraries I've written mostly this way:
- https://github.com/franciscop/brownies
- https://github.com/franciscop/files
- https://github.com/franciscop/backblaze
Documentation Driven Design
Or “literate programming”
Or “literate programming”
Better article: https://dev.to/cheetah100/domain-driven-disaster-147i
The biggest flaw of DDD I've run into is there's no emphasis on when not to use it. There's no mention that over-coding business rules into modules and services locks you into businesses processes that are slow or impossible to update. There's no mention that most times you want to build services that offer platform capabilities, not focus on what "domain" they fall into. Nevermind that "domain" is basically undefined and can mean many different concepts and different types of concepts. DDD has some decent and good ideas, and is over extended to "this is how you should set up everything." Build more platforms where the domain logic exists in user land, not in code land. Everyone will be more productive for it.
The book Domain Driven Design is also terribly written. Good ideas written by someone who should not communicate with humans.
The biggest flaw of DDD I've run into is there's no emphasis on when not to use it. There's no mention that over-coding business rules into modules and services locks you into businesses processes that are slow or impossible to update. There's no mention that most times you want to build services that offer platform capabilities, not focus on what "domain" they fall into. Nevermind that "domain" is basically undefined and can mean many different concepts and different types of concepts. DDD has some decent and good ideas, and is over extended to "this is how you should set up everything." Build more platforms where the domain logic exists in user land, not in code land. Everyone will be more productive for it.
The book Domain Driven Design is also terribly written. Good ideas written by someone who should not communicate with humans.
Engineering is like 50% about what you actively choose to not do, 40% making sure nobody else does it, and 10% doing it.
Thanks for sharing the article! The idea of making a framework for executing business logic that can be dynamically defined by users is old. It is realised in rule engines, embedded scripting, DSLs.
As usually, no silver bullet, but a good solution for right cases. Domain experts are given a tool to express and run the domain logic with different grades of flexibility without reliance on software engineers for coding and deployment. In theory.
Now the domain is expressed in both the tool and user configs. It may be difficult to find the right balance between flexibility and pushing complexity on end users and their configs. There is a real risk to make wrong choices here.
Another issue is that the more flexibility the tool provides is the stronger is the need across domain experts to manage the changes in business logic: review, rollback, logs - basically you want to have mini-Git and proto-CI/CD.
Also, the tool itself can require complex installation and maintenance. It will definitely be more resources-hungry comparing to a similar hardcoded solution - it is a payment for flexibility. The tool can scale, if it was a design decision - think about resource allocation in Apache Spark, Mesos, kubernetes.
Do not forget that now users need to learn your tool - I think teaching advanced Excel courses provides food on the table for many people.
As usually, no silver bullet, but a good solution for right cases. Domain experts are given a tool to express and run the domain logic with different grades of flexibility without reliance on software engineers for coding and deployment. In theory.
Now the domain is expressed in both the tool and user configs. It may be difficult to find the right balance between flexibility and pushing complexity on end users and their configs. There is a real risk to make wrong choices here.
Another issue is that the more flexibility the tool provides is the stronger is the need across domain experts to manage the changes in business logic: review, rollback, logs - basically you want to have mini-Git and proto-CI/CD.
Also, the tool itself can require complex installation and maintenance. It will definitely be more resources-hungry comparing to a similar hardcoded solution - it is a payment for flexibility. The tool can scale, if it was a design decision - think about resource allocation in Apache Spark, Mesos, kubernetes.
Do not forget that now users need to learn your tool - I think teaching advanced Excel courses provides food on the table for many people.
One of the things that rubs me wrong are articles that present a solution with no downside. Even if I were to mostly agree with the article you quoted, surely there must be downsides to the "functional architecture"? And, sure enough, it's fairly easy to come up with them:
a. Configuration complexity: if your system is generic & simple, sometimes the complexity doesn't go away, it just moves. As in the excel case quoted by the author - sometimes those excel files become a horrible unmaintainable mess that just produce wrong results and nobody can really tell. Sure, your architecture is nice, but did you make life good for the users? There's something to be said about the qualities of domain-driven software, here...
b. Performance (as opposed to scalability). It's often much harder (though not impossible!) to optimize the system if it's business rules are written in the configuration. Try doing machine learning in excel... it's theoretically possible, right? And yes you can get better performance by scaling horizontally to some extent, but then you risk running a hard-to-maintain-and-costly distributed system instead of a single machine that could do everything well.
a. Configuration complexity: if your system is generic & simple, sometimes the complexity doesn't go away, it just moves. As in the excel case quoted by the author - sometimes those excel files become a horrible unmaintainable mess that just produce wrong results and nobody can really tell. Sure, your architecture is nice, but did you make life good for the users? There's something to be said about the qualities of domain-driven software, here...
b. Performance (as opposed to scalability). It's often much harder (though not impossible!) to optimize the system if it's business rules are written in the configuration. Try doing machine learning in excel... it's theoretically possible, right? And yes you can get better performance by scaling horizontally to some extent, but then you risk running a hard-to-maintain-and-costly distributed system instead of a single machine that could do everything well.
If the flaw of DDD is that there is no emphasis on when not to use it, then the flaw of Peter's article is that, according to him, you should never use it ("software should be designed around function rather than domain").
I agree with his point that DDD will restrict an application that could be generic to a specific domain. When you can build something generic you should. But not everything can be made that way.
Also: "someone who should not communicate with humans" is a little bit too much.
I agree with his point that DDD will restrict an application that could be generic to a specific domain. When you can build something generic you should. But not everything can be made that way.
Also: "someone who should not communicate with humans" is a little bit too much.
You make some valid points, but “good ideas written by someone who should not communicate with humans” - a bit harsh don’t you think?
After reading all 500 grueling pages of DDD, that could have been 50 pages, no, I do not regret my hyperbole.
I do think it’s harsh that Eric Evans charges up to $4,000 a head for DDD workshops.
I do think it’s harsh that Eric Evans charges up to $4,000 a head for DDD workshops.
Here you go : https://www.infoq.com/minibooks/domain-driven-design-quickly... ~100pages
Here a smaller one: https://github.com/engma/ddd-inanutshell
Here a smaller one: https://github.com/engma/ddd-inanutshell
At least it was hyperbole, thanks fir the clarification.
I love technical reading but found DDD a really hard book to get through. I've been meaning to read the Vaughn Vernon books to figure out if they're an easier read for when I feel like I need to refresh my memory.
I found his Effective Aggregate Design pdfs very helpful https://www.dddcommunity.org/library/vernon_2011/, in addition to the DDD quickly book on Infoq, and Functional and Reactive Domain Modeling by Debasish Ghosh https://www.manning.com/books/functional-and-reactive-domain...
Have you tried Scott Wlaschin's book. It's a very easy read.
I haven't, is this the one? https://www.amazon.co.uk/Domain-Modeling-Made-Functional-Dom...
That is the one. It's also an introduction to structuring an F# application so it might not be for everyone but it's an easy read.
Also I'd recommend getting it from here. https://pragprog.com/titles/swdddf/domain-modeling-made-func...
Just because I personally like the pragprog site.
Also I'd recommend getting it from here. https://pragprog.com/titles/swdddf/domain-modeling-made-func...
Just because I personally like the pragprog site.
I’ll give it a shot - I’ve done some FP so I’m not put off by F#.
Thanks!
Thanks!
The way I see it is that DDD works well with very consolidated process modelling. Think finance, insurance, but also e-commerce, billing systems, etc.
If your business is for example into "data" processing or in the discovery phase at a startup, then I can see how DDD can feel like ultra over-engineering. But it has its place, for sure.
> The biggest flaw of DDD I've run into is there's no emphasis on when not to use it
Except that there's literally an entire chapter in the book on Generic Subdomains. It says to move everything that is not the critical motivation for the project out of the core, give it lower prio, put junior devs on it, or outsource it entirely.
Except that there's literally an entire chapter in the book on Generic Subdomains. It says to move everything that is not the critical motivation for the project out of the core, give it lower prio, put junior devs on it, or outsource it entirely.
That article misses some important nuances. Yes hard coding business logic can land you in hot water. But you don't need to do that domain driven design. What you do need is the domain to specify the flexibility of your design. Almost all business need an accounting system. An accounting system can be built following domain driven development. But for it to be useful to many businesses it must be flexible. So the rules around standard accounting ( the domain ) will be hard coded. But the system can still be configurable as the domain is too.
To elaborate —
Domain driven design is about understanding the business requirements enough to know “this is fundamental to the domain” versus “this is going to change next month”.
In the accounting example, when you talk to the accountants and develop an ubiquitous language, you’ll notice that long term concepts are “assets”, “transactions”, “taxes”, etc. while the transient things are exact tax rates, how transactions are structured (eg, net 30), etc.
So you’d build your system to match:
- A foundation of transacting assets/currency/inventory
- A system for defining transaction flows
- A system for reporting transaction aggregates (eg, for tax filings)
Domain driven design doesn’t say which of those to hardcode versus make user configurable — it says to talk to your users until you understand the domain, then build software that reflects that.
Like most good ideas, people get way too formulaic about it sometimes.
Domain driven design is about understanding the business requirements enough to know “this is fundamental to the domain” versus “this is going to change next month”.
In the accounting example, when you talk to the accountants and develop an ubiquitous language, you’ll notice that long term concepts are “assets”, “transactions”, “taxes”, etc. while the transient things are exact tax rates, how transactions are structured (eg, net 30), etc.
So you’d build your system to match:
- A foundation of transacting assets/currency/inventory
- A system for defining transaction flows
- A system for reporting transaction aggregates (eg, for tax filings)
Domain driven design doesn’t say which of those to hardcode versus make user configurable — it says to talk to your users until you understand the domain, then build software that reflects that.
Like most good ideas, people get way too formulaic about it sometimes.
Interesting to see all of the discussion on hard-coding vs configuring domain/business logic, when in reality most line-of-business app developers are never introduced to the very concept of business/domain logic, and therefore it gets strewn all throughout an application’s code based, tangled in with data retrieval, u/i concerns, and everything else.
Yes — the goal of DDD is to explain why that’s a bad idea. For two reasons.
1. It makes your code a mess.
2. You probably wrote the wrong thing anyway, because how do you know what the customer wants if you don’t even know what they do?
DDD argues you should develop software by:
1. Talking to customers about the domain until you have a shared language with specific terminology.
2. Write that down as a model.
3. Write that model as software.
I think one of the biggest misses in software engineering (and something I’ve seen cost $100Ms) is software developers not talking to customers about what they do with the software. Some of the worst bugs happen because domain experts mean something by a term of art that software developers misunderstand.
DDD overlaps heavily with the “applied category theory” perspective on software, so DDD tends to be popular with functional programming types.
1. It makes your code a mess.
2. You probably wrote the wrong thing anyway, because how do you know what the customer wants if you don’t even know what they do?
DDD argues you should develop software by:
1. Talking to customers about the domain until you have a shared language with specific terminology.
2. Write that down as a model.
3. Write that model as software.
I think one of the biggest misses in software engineering (and something I’ve seen cost $100Ms) is software developers not talking to customers about what they do with the software. Some of the worst bugs happen because domain experts mean something by a term of art that software developers misunderstand.
DDD overlaps heavily with the “applied category theory” perspective on software, so DDD tends to be popular with functional programming types.
This is literally why Fowler and Evans wrote their books, some of this "tangling" was viewed as a feature because it let a single dev own an issue and avoided the bottleneck of architecture by committee.
[deleted]
Like many things that have the potential to make you feel clever, e.g. machine learning, functional programming, DDD can easily be overused / used for the wrong reasons, at least if it's not mastered to a certain level.
When I first learned about DDD in 2008 or so, I was so proud of myself that each and every service was DDDified, which really put a huge mental burden on me and my team. It is not only that you have to think really deeply about your domain (which is usually a good thing) but you often come to a point where doing things the DDD way means a lot more work, e.g. creating Anti-Corruption Layers between bounded contexts. I spent so much time researching if I do things correctly and if the acknowledged prophets consider a design decision acceptable that coding started to hurt.
At some point however - and I think this what happens whenever you master something sufficiently - the penny dropped that the subtitle of the Eric Evans book "Tackling complexity in the heart of the software" really meant something: that DDD was a method for building complex software. The book itself - if you read it carefully as I did many years later - says explicitly that you should not use DDD for most parts of your system but only complex "core domains".
Nowadays, I am designing most services as "Transaction Scripts" again. Without feeling guilty.
When I first learned about DDD in 2008 or so, I was so proud of myself that each and every service was DDDified, which really put a huge mental burden on me and my team. It is not only that you have to think really deeply about your domain (which is usually a good thing) but you often come to a point where doing things the DDD way means a lot more work, e.g. creating Anti-Corruption Layers between bounded contexts. I spent so much time researching if I do things correctly and if the acknowledged prophets consider a design decision acceptable that coding started to hurt.
At some point however - and I think this what happens whenever you master something sufficiently - the penny dropped that the subtitle of the Eric Evans book "Tackling complexity in the heart of the software" really meant something: that DDD was a method for building complex software. The book itself - if you read it carefully as I did many years later - says explicitly that you should not use DDD for most parts of your system but only complex "core domains".
Nowadays, I am designing most services as "Transaction Scripts" again. Without feeling guilty.
The author is a fan of DDD (despite the title) and so am I. In fact I'd argue that DDD is just about the only way that you could possibly do work that can be categorized as "systems design". You either do it with the knowledge of the common sticking points of DDD or you don't.
If you're writing a subroutine in a device driver or some other similarly specific task, then you don't need to do design. You can be clever or not clever, but what you're doing is building a flexible solution. If you're designing a system, it necessarily operates in a domain (and/or creates it's own), and DDD is one of the best tools for trying to building language and feeling out where abstraction can/should be.
What the author seems to be wary of (which I agree with) is the cargo cult and legion of consultants pushing it. This article is essentially "use the right tool for the job, it's not always DDD", and I agree with the premise... but DDD is amazing when it's done well you can build systems that are easy to understand, manipulate and extend.
If you're writing a subroutine in a device driver or some other similarly specific task, then you don't need to do design. You can be clever or not clever, but what you're doing is building a flexible solution. If you're designing a system, it necessarily operates in a domain (and/or creates it's own), and DDD is one of the best tools for trying to building language and feeling out where abstraction can/should be.
What the author seems to be wary of (which I agree with) is the cargo cult and legion of consultants pushing it. This article is essentially "use the right tool for the job, it's not always DDD", and I agree with the premise... but DDD is amazing when it's done well you can build systems that are easy to understand, manipulate and extend.
And I thought this article was about the Data Display Debugger https://www.gnu.org/software/ddd/ :D
Me too. I think it is quite old too, going back to 80's?
This feels like clickbait. It seems like the conclusion is something like “DDD done well is really good, but not perfect” which I can’t take action on. Maybe a concrete example of when it doesn’t work well would help?
I’ve understood DDD to essentially be “focus on the business and here are some helpers that might make you more effective in doing so.” Do others find it overly prescriptive?
I’ve understood DDD to essentially be “focus on the business and here are some helpers that might make you more effective in doing so.” Do others find it overly prescriptive?
What he probably means ( he doesn't go into details), is that you can create a simple monolith without splitting up everything.
Which is basically true.
But as soon as you go more complex, you'll probably wish you'd used DDD from the start.
DDD is gaining traction, not because it's good. But because it's compatible with microservices.
As an aside, i also like how jgobard developped ContosoUniversity ( https://github.com/jbogard/ContosoUniversityDotNetCore / https://github.com/jbogard/ContosoUniversity/tree/master/src... ) with vertical slices and feature folders.
Which is basically true.
But as soon as you go more complex, you'll probably wish you'd used DDD from the start.
DDD is gaining traction, not because it's good. But because it's compatible with microservices.
As an aside, i also like how jgobard developped ContosoUniversity ( https://github.com/jbogard/ContosoUniversityDotNetCore / https://github.com/jbogard/ContosoUniversity/tree/master/src... ) with vertical slices and feature folders.
I think it is often more helpful to ask the question "To what extent is XDD useful in context Y?". This firstly shifts the discussion away from whether something is universally good or bad (the space of bandwagon riders and hype curve surfers), and secondly avoids trying to comment on what one believes to be the popular opinion at some particular point in time.
Perhaps the difficulty tho is that DDD in particular is a collection of ideas that I would opine might have quite different profiles in terms of both their applicability, and range of design scope. Ubiquitous Naming seems like its pretty widely applicable, and by its very nature is about building consensus within teams, whereas Repository, Factory, Service, Aggregate feel like they could be the dishes served up at some Object Oriented dinner party where the guests could quite justifiably argue long into the night about what the best model design should be.
Perhaps the difficulty tho is that DDD in particular is a collection of ideas that I would opine might have quite different profiles in terms of both their applicability, and range of design scope. Ubiquitous Naming seems like its pretty widely applicable, and by its very nature is about building consensus within teams, whereas Repository, Factory, Service, Aggregate feel like they could be the dishes served up at some Object Oriented dinner party where the guests could quite justifiably argue long into the night about what the best model design should be.
This is a perfect hn, reddit blog post. Controversial title catching points even if people don't read it. Simple contents that are easy to disagree with and broad topic that has a lot of meta. Karma production machine
I’m a bit late to the party on this but the article fundamentally misunderstands DDD. DDD explicitly doesn’t concern itself with implementation details. It doesn’t have an opinion on DB servers, how you should partition data, etc.
DDD is a way of modelling your business logic. Your domain doesn’t care about databases or servers, these are details at the edges of your application.
If your domain does need to care about the details of how it runs on servers and databases, then perhaps DDD is not the right tool for the job.
DDD is a way of modelling your business logic. Your domain doesn’t care about databases or servers, these are details at the edges of your application.
If your domain does need to care about the details of how it runs on servers and databases, then perhaps DDD is not the right tool for the job.
DDD has the same foundation as Agile:
Complex problems (domains) require explorative and iterative aproaches (like science always did), complicated or simple domains don't need that.
And if you don't know the problem - then don't start doing anything. If you don't understand yourself well enough and cannot isolate a logical model, than stop, too.
For me, that's both timeless wisdom, and nothing special.
And if you don't know the problem - then don't start doing anything. If you don't understand yourself well enough and cannot isolate a logical model, than stop, too.
For me, that's both timeless wisdom, and nothing special.
This article says nothing about DDD and all about how the author is coping with its gaining traction.
I myself find DDD a pilar I don't want to work with anymore.
I myself find DDD a pilar I don't want to work with anymore.
It seems that their primary gripe relates to the naming of certain concepts. The article does not support the headline.
[deleted]
I came here expecting a critique of the DDD debugger :(
My organization was in the hype about DDD for years, so I practiced it for quite some time. I would say many parts of it is overrated. But there's still great parts. Here's what I learned:
1. It's a specific version of Model-driven Architecture. And the idea is very close to Hexagonal Architecture, Clean Architecture
2. There are a lot of cases when it's not worth it. If you don't have the vision to evolve your system for more than 3 years just forget about it.
3. Strategic design is more important than tactical design. You can adopt the former without the latter. If you only adopt the latter it doesn't help.
4. You don't have to adopt Microservice combined with DDD.
5. Start with coarse-grained Bounded Contexts if you're not experienced. Incorrectly fine-grained Bounded Context is simply painful.
The Good:
1. Ubiquitous languages. Even if you're not doing DDD it's a very good idea to keep in mind.
2. Strategic design. Microservices usually creates more problems than it solves, the idea of splitting Bounded Contexts helps to ease some pain of building Microservices.
3. The Aggregate. If you're doing tactical design, pay most attention to the Aggregate design.
The Bad:
1. Tactical design, the jargons like the Repositories, Domain Service, etc. IMO It's better to do the strategic stuff only, draw the Bounded Context, and let the autonomous teams do the implementation and forget the tactical stuff. They'll be motivated, feel fulfilled, and willing to improve the architecture of the fraction for themselves. In contrast to the Wizard vs Grunts (the Model Scientist vs Implementation Engineers) relations that are often seen in the financial industry.
2. The tactical jargons IMO are transient. They'll probably be starting to die out in a decade, just like most of the patterns described in the 'Patterns of Enterprise Application Architecture' from Martin Fowler.
The Ugly:
1. Don't expect you'll build models that aren't leaky. For example, your seemingly perfect model will still include tech infrastructures like Stream<User> or Flux<User>, unless you are using advanced languages like Scala and can parametrize them as TMonad<User>
2. Although it claims to help you to build pure models, the platform you're targeting will most likely still decide your model - if you're doing a traditional HTTP request/response Web project, your model will likely be a request/response one. If you think you're dreaming that you can use the same model for a real-time WebSocket project, or even a conflict-free collaborative project, good luck. You can build a real-time model in the first place, but it would be much more expensive.
3. The Repository pattern and the Aggregate pattern are like a trade-off to each other. The Aggregate wants to be rich and contain more domain logic, while the Repository stops them from being rich. As a comparison, the Active Record is much easier to be rich compared to the Repository, but it defeats the goal of being infrastructure agnostic. So if you're convinced you're going to do Web-only you can switch to Active Record + Aggregate rather than Repository. Just like 'Rails IS your application' according to DHH.
1. It's a specific version of Model-driven Architecture. And the idea is very close to Hexagonal Architecture, Clean Architecture
2. There are a lot of cases when it's not worth it. If you don't have the vision to evolve your system for more than 3 years just forget about it.
3. Strategic design is more important than tactical design. You can adopt the former without the latter. If you only adopt the latter it doesn't help.
4. You don't have to adopt Microservice combined with DDD.
5. Start with coarse-grained Bounded Contexts if you're not experienced. Incorrectly fine-grained Bounded Context is simply painful.
The Good:
1. Ubiquitous languages. Even if you're not doing DDD it's a very good idea to keep in mind.
2. Strategic design. Microservices usually creates more problems than it solves, the idea of splitting Bounded Contexts helps to ease some pain of building Microservices.
3. The Aggregate. If you're doing tactical design, pay most attention to the Aggregate design.
The Bad:
1. Tactical design, the jargons like the Repositories, Domain Service, etc. IMO It's better to do the strategic stuff only, draw the Bounded Context, and let the autonomous teams do the implementation and forget the tactical stuff. They'll be motivated, feel fulfilled, and willing to improve the architecture of the fraction for themselves. In contrast to the Wizard vs Grunts (the Model Scientist vs Implementation Engineers) relations that are often seen in the financial industry.
2. The tactical jargons IMO are transient. They'll probably be starting to die out in a decade, just like most of the patterns described in the 'Patterns of Enterprise Application Architecture' from Martin Fowler.
The Ugly:
1. Don't expect you'll build models that aren't leaky. For example, your seemingly perfect model will still include tech infrastructures like Stream<User> or Flux<User>, unless you are using advanced languages like Scala and can parametrize them as TMonad<User>
2. Although it claims to help you to build pure models, the platform you're targeting will most likely still decide your model - if you're doing a traditional HTTP request/response Web project, your model will likely be a request/response one. If you think you're dreaming that you can use the same model for a real-time WebSocket project, or even a conflict-free collaborative project, good luck. You can build a real-time model in the first place, but it would be much more expensive.
3. The Repository pattern and the Aggregate pattern are like a trade-off to each other. The Aggregate wants to be rich and contain more domain logic, while the Repository stops them from being rich. As a comparison, the Active Record is much easier to be rich compared to the Repository, but it defeats the goal of being infrastructure agnostic. So if you're convinced you're going to do Web-only you can switch to Active Record + Aggregate rather than Repository. Just like 'Rails IS your application' according to DHH.
> 1. Don't expect you'll build models that aren't leaky. For example, your seemingly perfect model will still include tech infrastructures like Stream<User> or Flux<User>, unless you are using advanced languages like Scala and can parametrize them as TMonad<User>
I'm a Scala dev and I know monads, but what exactly is TMonad<User>? Like `[T: Monad](users: T[Users])`?
> 2. Although it claims to help you to build pure models, the platform you're targeting will most likely still decide your model
I think that is a crucial point. In fact, the platform _is_ very often part of the domain and should be part of the language in DDD. It's one of the reasons why no-code solutions fail and why there is often a mismatch between developers and product-team - the latter does not see these things as part of the domain, but they are and if you don't describe them as it, there quickly is a mismatch between dreams and reality.
I'm a Scala dev and I know monads, but what exactly is TMonad<User>? Like `[T: Monad](users: T[Users])`?
> 2. Although it claims to help you to build pure models, the platform you're targeting will most likely still decide your model
I think that is a crucial point. In fact, the platform _is_ very often part of the domain and should be part of the language in DDD. It's one of the reasons why no-code solutions fail and why there is often a mismatch between developers and product-team - the latter does not see these things as part of the domain, but they are and if you don't describe them as it, there quickly is a mismatch between dreams and reality.
> I'm a Scala dev and I know monads, but what exactly is TMonad<User>? Like `[T: Monad](users: T[Users])`?
Pretty much like it. There's a popular pattern called Tagless Final which lets you parametrize it and then swap the implementation in the last step.
In this way the model layer wouldn't know the underlying implementation is Future, Promise, or Flux. Sometimes it's useful because the developer finds it's painful to migrate from libraries to libraries.
Pretty much like it. There's a popular pattern called Tagless Final which lets you parametrize it and then swap the implementation in the last step.
In this way the model layer wouldn't know the underlying implementation is Future, Promise, or Flux. Sometimes it's useful because the developer finds it's painful to migrate from libraries to libraries.
tl;dr but i wholeheartedly disagree. i can live without the lingo but the concepts are incredibly important. especially in large and complex projects. even though, in essence, it is all merely about encapsulation of data and actions that can be performed with/on them within context. it is good to have some general understanding of what is actually being done, conceptually. and having a philosophy with a name helps.
DDD principles are very helpful and "robust" but they address, specifically, untangling complex domains and requirements: sometimes it's the main software design challenge, but often other aspect of architecture that DDD doesn't have a lot to say about are much more difficult and/or important.
For example, from a domain driven point of view Awk operates on a simple structural hierarchy of input and output files, lines and fields; designing a nice DSL around the obvious operations on these entities is clearly a much greater achievement than designing (or rather postulating) this model.
For example, from a domain driven point of view Awk operates on a simple structural hierarchy of input and output files, lines and fields; designing a nice DSL around the obvious operations on these entities is clearly a much greater achievement than designing (or rather postulating) this model.
Not even going to read it, because of the stupid click bait title.
It was a great debugger in its time, with some unique features. True, its development was abandoned at long time ago, but saying that it is "overrated" seems a bit unfair.
The article is about Domain Driven Delopment, not the ddd debugger.
The best DDD-related thing I've read is the paper "Programming as if the domain (and performance) mattered": https://drive.google.com/file/d/0B59Tysg-nEQZSXRqVjJmQjZyVXc... One of the lessons I took from it is that too often as programmers we look at a problem and immediately try to transform it to some other problem, typically in a more abstract domain. Often this is fruitful, and our formal education (not to mention whiteboard-hazing interview practices) centers around pounding this into our heads with reusable data structures and algorithms. But also often it leads to something harder to evolve, not as fit for the original purpose, and more confusing (especially to those unfamiliar with the abstractions used). If DDD does nothing but make us challenge that default mode of thought and consider not doing problem transformation immediately every time, it's a worthwhile endeavor.
Another resource I widely recommend is the book Thinking Forth (http://thinking-forth.sourceforge.net/) It has many lessons applicable today on software design, including some useful thoughts on a program's "lexicon" that are somewhat DDD-related.