DDD Is Overrated
tilkov.com
tilkov.com
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.
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.
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.)
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).
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!
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.
speaking of which, ddd is the only application I have installed that relies on motif...
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
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'?"
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.
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.
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.
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 :-)
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.
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.
Or “literate programming”
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.
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
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.
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.
Thanks!
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.
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.
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.
I do think it’s harsh that Eric Evans charges up to $4,000 a head for DDD workshops.
Here a smaller one: https://github.com/engma/ddd-inanutshell
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
I myself find DDD a pilar I don't want to work with anymore.
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.
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.
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.
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.