14

What is the problem that is solved by Domain Driven Design?

I understand what Object Oriented Programming brought and see the issues it addressed and how, and in what aspect/scenaria, it made the live of a developer easier. But I so far failed to see the big picture of what DDD does bring us. For sure this is due to the fact that I am just starting with DDD and maybe it is something I will just know at the end (after working with it for some years). But if not and it is possible to summarize the big picture in some sentences please share them with me.

What I got so far:

DDD helps to define a common language to discuss a software project for example. To understand what is happening in a domain, e.g. how the business works, what operations are possible and under which conditions. What data has to be stored and how it should be grouped.

Is this the big picture? I think there is more to it but I cannot yet see it.

Edit

There exists a similar question What is Domain Driven Development in practical terms?. However this question has a different focus when asking what DDD is while I would like to learn to what problem DDD is the solution. One given answer to that is really excellent and does also include possible answers to my question. I cannot judge whether this answer includes the complete answer to my question but right now my intuition tells me it does not.

Community
  • 1
Sjoerd222888
  • 669
  • 5
  • 18
  • 11
    Eric Evans, the creator of DDD and author of the DDD book has said that DDD is really just a catchy name for "good object-oriented design" and that he didn't invent anything, he just wrote it down and gave it a name. Similar to how Kent Beck says that TDD has been around for decades, he just gave it a name and wrote a book about it. Or the GoF didn't invent design patterns, they simply collected them. – Jörg W Mittag Dec 14 '15 at 17:45
  • 1
    I disagree with the "duplicated question", I think they are similar but not the same. However, I posted my answer there: http://programmers.stackexchange.com/questions/123023/what-is-domain-driven-development-in-practical-terms – ZioBrando Dec 16 '15 at 12:08
  • @JörgWMittag do you have a reference for Eric saying that DDD is simply good OOD? Is it in the book? – Steven Shaw Mar 18 '17 at 02:36
  • I think that DDD rather stands for Domain Driven Design than Development. And that is because it addresses more Architectural and Design issues rather than development. – ACV Feb 24 '21 at 20:04

2 Answers2

14

Domain Driven Design is fundamentally a remedy for our tendency to bleed the technical and "philosophical" objects and concerns into each other. Even in cases where we have a strong sense that these two things are best addressed as separate concerns, it can be tough to consistently make the right divisions without a clear rule.

And so, the basic rule is, "create and maintain a distinctly recognizable part of your application (the domain) into which you contain your pure, business-recognizable objects and methods, the names of which any business person should recognize."

It's about avoiding the situations wherein both the business rules and the technology are hard to change because they're not well-isolated from each other.

In my own experience with web applications, I've found that when DDD and DDD-like principles are not explicitly adhered to, there is a strong tendency to bake business rules right into UI code. So, you end up with multiple copies of business rules (one for each page), and neither those UI's nor the business rules can be easily changed.

svidgen
  • 13,414
  • 2
  • 34
  • 60
5

I think DDD deals with a somewhat understated concept, which I call the "Problem/Solution Separation". And it solves the issue of Problem Reuse instead of just Solution Reuse.

As I see it, you should model problem elements in a way that is not dependent on how it would be solved. That would be the "analysis" part of OOAD, where you define conceptually what are the elements of the problem. Meanwhile, as you go further developing your solution - that is, designing one of the possible solutions - you add elements that pertain specifically to that solution. That would be the "design" part of the application, where you define how those elements from the problem should be manipulated, or how they are expected to interact so that the problem is solved.

As a concrete example, I develop medical software (biosignal data-capturing, processing and visualization, mostly). Our company has a handful of software products, each solving quite similar problems in slightly different ways, depending on medical specialty. Upon analysis, that is, analysis of the problem, we've seen the same recurring concepts over and over. Those concepts were designed into objects (or interfaces, or abstract classes), and put in an assembly called Company.BioSignals.DomainModel. Now we have a one-to-many mapping between a problem-related, circumscribed part of the codebase, and a set of solution-related parts of the codebase.

heltonbiker
  • 1,038
  • 1
  • 9
  • 17
  • UP, "problem/solution separation" - the why of [the book.](http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215). I quit reading about half way because I didn't get why I was reading this. Ok, so It's a design framework - another layer and as such inherently makes it harder to couple the UI and business logic (see svidgen's answer). But I'm jaded, the state of our code is not for lack of framework (google CLSA) rather the result of programmers who fundamentally do not grok *minimize coupling and maximize cohesion.* – radarbob Dec 14 '15 at 21:05