-4

I want to understand the Domain-Driven Design approach, how it works, and what it includes in its Definition.

TLDNR

What is the mental framework behind DDD? What are the core components of DDD? How are the elements applied?

Update

I will keep updating this post after the helpful post. If you are like me and want to understand overall context and ideas before reading a whole book you can check out my oversimplified, general hints.

Problem/Context

  • How to structure an application?
  • How to decompose an application into services or concerns?

"I have a big program but whenever I ask for a change the developers say its hard/impossible because of the way they have written it. Things that seem obvious to me like 'Orders can be cancelled' apparently require a whole redesign of what an 'Order' is.?!?"

Solution

  • Domain-Driven Design

Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, this book prevents an extensive set of design practices, techniques, and principles.

Function

  • have a common language - UbiquitousLanguage practice of building up a common, rigorous language between developers and users.
  • ModelDrivenSoftwareDevelopment- centers on building models of a software system
  • Bounded Context - segregating the application into different spheres
  • ...

The question is focuses on the function. After skimming some books Evans'- domain driven design and Khononov - Learning Domain-Driven Design it is still unclear what Domain Driven Design is.

In both books, I missed a clear definition of what it is and what separates it from other approaches.

Opinion: This is very unspecific since, as I understand it, there is no precise algorithm on how to apply DDD - which was not intended. In the same argument, it is said that it is more of a mental framework. But this is precisely my question.

Improve this question
3
  • 1
    Perhaps it'll help if you expand the problem/context statement, or the premise, with these: (1) miscommunication/misunderstanding happens in every aspect of life more often than people are aware; furthermore, people use the same words to mean subtly (and sometimes wildly) different things, and this is often unnoticed, (2) a software firm is an outsider and lacks context and subtle understanding that the domain experts have; domain experts aren't aware of software-related subtleties, ... Commented Nov 7, 2021 at 18:57
  • 1
    (3) these discrepancies directly influence 3a) how well (or how badly) the software supports the actual needs of the people it's built for, and 3b) how much of a tangled, unmaintainable mess it's going to become over time. So (4) a set of principles/practices/heuristics is needed to manage faulty communication and discover unwarranted assumptions, and to really understand the domain and figure out what is it that needs to be built, as any design effort and structuring/decomposition strategy depends on this to a large extent. Commented Nov 7, 2021 at 18:57
  • 1
    "After skimming some books" - "I missed a clear definition of what it is" - maybe that's the problem? Just skimming is probably not enough when it comes to a topic like DDD. Commented Nov 8, 2021 at 6:40

3 Answers 3

Reset to default
7

If you want to understand a programming methodology the best approach is to ask yourself "What problem is this meant to solve?"

Such methodologies tend to share a whole bunch of "standard" advice, write tests, split code into small parts, be clear etc, the author isnt trying to tell you how to write good code, they are trying to tell you how to solve a problem that they have seen.

So Scrum or agile in general, is solving "Big programs take ages to write and end up not matching the requirements at the time of finishing"

Micro-services is solving "'Monolithic' program are hard to add to or edit small parts of

TDD is solving "No-one writes tests and we end up with a massive codebase with no tests"

DDD is solving: "I have a big program but whenever I ask for a change the developers say its hard/impossible because of the way they have written it. Things that seem obvious to me like 'Orders can be cancelled' apparently require a whole redesign of what an 'Order' is.?!?"

This is a common problem, developers write code to meet requirements and businesses are bad at writing requirements. The answer? try and get the business and the code to speak the same language, understand the business and write the code to match that understanding rather than optimise to the requirements of the day.

Improve this answer
2
  • 1
    +1 Two comments; the scrum/agile & DDD problem-statements are kind of two sides of the same coin ('Orders can be canceled' cannot be easily supported ≈ software not actually matching the requirements (or needs of the business), although the path to the resulting state of affairs might have been (ostensibly) different). Commented Nov 8, 2021 at 4:05
  • 2
    Second comment: "developers write code to meet requirements" - the problem starts, really, right there; many companies have turned their developers into "requirement processors", with the requirements coming from an external source, when, if you want to do Agile or DDD, it's the dev team who should be hired to work together with the customer towards defining what the problem actually is, capture their findings as a model of the problem domain & a requirements spec, and get paid handsomely for that, on top of getting paid for actually implementing and delivering the software. Commented Nov 8, 2021 at 4:05
6

The term was invented by Eric Evans, so his book is the definition of what Domain-Driven Design is.

Your quote, from the preface of Evans' book, is only a partial description of what DDD is. Consider this longer quote:

Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, this book prevents an extensive set of design practices, techniques, and principles.

Domain-driven design is a set of "design practices, techniques, and principles". Although Evans' book talks about all three, the principles are going to be the most stable over a long period of time, while new techniques and practices may emerge alongside or to replace some of the techniques and practices described in the book.

I'm not sure if there are multiple versions of Evans' book, but my version has a diagram of the practices and techniques on inside of the front and back cover. The core practices are Ubiquitous Language and Model-Driven Design. These support or are supported by a large number of other practices and techniques, including Intention-Revealing Interfaces, Layered Architectures, and Continuous Integration. All of the practices are described in detail by Evans in the book.

I would suggest reading Evans' book thoroughly to understand how the principles, practices, and techniques fit together to form a cohesive design strategy for dealing with complex domains.

Improve this answer
3
  • 1
    I remember an interview with Eric Evans where he said that DDD is essentially just good OO design, as it has always been practiced; he didn't invent it, he just wrote down what everybody was doing anyway and gave it a catchy title. Commented Nov 7, 2021 at 12:41
  • 1
    @JörgWMittag That's often how patterns are discovered. Looking at structures in OO systems is how the Gang of Four developed the patterns in their book. It's all about looking for common structures and then describing them at the right level of abstraction. On a process side, it's also how Cockburn developed the Crystal methodologies - talking to teams building different types of systems, determining if they were successful or not, and identifying what practices they used. Commented Nov 7, 2021 at 12:45
  • Thank you for the hint with diagram. I am reading from screen and it was missing the diagram. Commented Nov 8, 2021 at 8:03
1

It is actually quite simple as Eric Evans and @Thomas Owens mentioned

Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, this book prevents an extensive set of design practices, techniques, and principles.

In other words it is just a set of pattern to solve issues when building an application. Such as @Ewans mentioned :

"I have a big program but whenever I ask for a change the developers say its hard/impossible because of the way they have written it. Things that seem obvious to me like 'Orders can be cancelled' apparently require a whole redesign of what an 'Order' is.?!?"

It uses the methods such as:

  • have a common language - UbiquitousLanguage practice of building up a common, rigorous language between developers and users.
  • ModelDrivenSoftwareDevelopment- centers on building models of a software system
  • Bounded Context - segregating the application into different spheres

Each point has for more points and nuances and can be check out in the referenced books.

N.B.: most of the time it boils down to many established principles such as SOLID with more abstract approach considering the user domain when drawing out the system. In comparison, to class/implementation side in SOLID.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.