While reviewing some résumés last week, my eyes were caught by this guy writing:
- I’ve recently been focused on migrating to a DDD architecture
And some lines further:
- Architecture redesign: Solution shifted first to MVC then DDD, multi-layered architecture implementation.
Apparently this guy tried to do some MVC but seemed not to be happy with it, so he decided to shift to DDD. This technique must certainly come from a secret chapter of Eric Evans’ Domain-Driven Design book that only this guy knows about! ;-)
Unfortunately this is not the first time I hear and see people confusing architecture and DDD.
A couple of weeks ago I went to a meetup where someone proposed to do a DDD Kata. I was quite enthusiast to participate and I started to imagine that we were going to do some Event Storming. Well, I must admit that I was quickly disappointed seeing the guy starting the kata by opening his favorite IDE. His idea was to do some code refactoring using DDD principles. To tell you the truth I was quite curious to see how he would manage to do so! The kata was similar to the Guilded Rose one; there was a lot of unreadable legacy code that you had to refactor to be able, at the end, to add a new feature without breaking the whole stuff. The guy quickly stated things like “as DDD tells us, let’s extract some interfaces so that we can put their implementations in another layer” Ouch! It took them some time (and a few remarks made by a couple of attendees) to realize that they were not doing any DDD at all.
So why do people keep on confusing DDD and architecture?
What I find as being the most likely explanation is that it’s due to the presence of the “design” term in Domain-Driven Design. But as Grady Booch says “All architecture is design, but not all design is architecture”.
DDD is not a technology; it’s a set of principles that will help you to deal with the complexity of an application domain by modeling it. DDD is focused on the domain and its logic where “Software architecture introduces structure and guidelines into a software system, leading to consistency and clarity” to quote Simon Brown.
But keep in mind that principles do impact your software architecture. Going with DDD will obviously lead you to choose the software architecture that will welcome it warmly. Architecture styles like Hexagonal Architecture or Onion Architecture will definitely help you to accomplish that as it will isolate the domain and avoid the business logic to be tightly coupled with any infrastructure related technology.
Should you go with DDD? Well, as it’s often the case, it depends! From my point of view it mainly depends on your domain complexity: the more complex it is the more you might benefit from DDD. But every choice comes with a cost; it will be up to you to evaluate the need and as Simon Brown says: “Principles are good, but make sure they’re realistic and don’t have a negative impact”!
Consultant et formateur
Si vous recherchez un accompagnement pour votre équipe ou une formation, je suis à votre disposition pour plus d’information, n’hésitez pas à me contacter !
one.hundred.acorns 
Couldn’t agree more. DDD is much like micro services or REST these days — everyone claims to be doing it, but they are merely reproducing one or two (usually technical) gimmicks that they read on some blog were typical of DDD.
People get carried away by the hype, but very few of them actually care to dig deeper into the basic concepts of DDD. I’m surprised by the number of them who show up on Stack Overflow or discussion boards and have not even read the “DDD Quickly” short version of the original blue book, let alone the book itself. Based on the questions I see, I’d say it’s the case 90-95% of the time.
As you pointed out, if people actually read the books maybe a majority would realize DDD is not a good choice in their context. Which can be a perfectly valid decision.
Thanks for your comment Guillaume.
Yes, people might realize that DDD is not a good choice for them if they read the book. But they could apply some of its principles anyway!
DDD is sort of a toolbox from where you can pick-up some nice things to put in place. I’ve recently made a presentation where I told people that they were not obliged to apply DDD from A to Z to define a Ubiquitous Language! The same goes for having multiple models depending on the context.
This is all good sense!
Nicely put! It’s kind of an old post but surely relevant till today. There is A LOT of confusion out there. I think mostly because people gather knowledge about something from only one place (one book, one talk,…) or because they don’t want to spend more time to elaborate on the understanding of a new technology that just have been taught.