What is Domain Driven Design (DDD)? [closed]

Question

I keep seeing DDD (Domain Driven Design) being used a lot in articles - I have read the Wikipedia entry about DDD but still can't figure out what it actually is and how I would go about implementing it in creating my sites?

Centavo

feel free to check this: youtu.be/MfEpw2WXXyk – Yaron

Answer 1

Firstly, if you don't know that you need it then it's possible that you don't need it. If you don't recognize the problems that DDD solves then maybe you don't have those problems. Even DDD advocates will frequently point out that DDD is only intended for large (>6 month) projects.

Assuming that you're still reading at this point, my take on DDD is this:

DDD is about trying to make your software a model of a real-world system or process. In using DDD, you are meant to work closely with a domain expert who can explain how the real-world system works. For example, if you're developing a system that handles the placing of bets on horse races, your domain expert might be an experienced bookmaker.

Between yourself and the domain expert, you build a ubiquitous language (UL), which is basically a conceptual description of the system. The idea is that you should be able to write down what the system does in a way that the domain expert can read it and verify that it is correct. In our betting example, the ubiquitous language would include the definition of words such as 'race', 'bet', 'odds' and so on.

The concepts described by the UL will form the basis of your object-oriented design. DDD provides some clear guidance on how your objects should interact, and helps you divide your objects into the following categories:

• Value objects, which represent a value that might have sub-parts (for example, a date may have a day, month and year)
• Entities, which are objects with identity. For example, each Customer object has its own identity, so we know that two customers with the same name are not the same customer
• Aggregate roots are objects that own other objects. This is a complex concept and works on the basis that there are some objects that don't make sense unless they have an owner. For example, an 'Order Line' object doesn't make sense without an 'Order' to belong to, so we say that the Order is the aggregate root, and Order Line objects can only be manipulated via methods in the Order object

DDD also recommends several patterns:

• Repository, a pattern for persistence (saving and loading your data, typically to/from a database)
• Factory, a pattern for object creation
• Service, a pattern for creating objects that manipulate your main domain objects without being a part of the domain themselves

Now, at this point I have to say that if you haven't heard of any of these things before, you shouldn't be trying to use DDD on any project that you have a deadline for. Before attempting DDD, you should be familiar with design patterns and enterprise design patterns. Knowing these makes DDD a lot easier to grasp. And, as mentioned above, there is a free introduction to DDD available from InfoQ (where you can also find talks about DDD).

Rogelioroger

Wow... What a great reply! Very appreciated and the best explanation I have read anywhere by a mile. Thanks.. I'll download that book tomorrow. – Centavo

"Aggregate roots are objects that own other objects. This is a complex concept and works on the basis that there are some objects that don't make sense unless they have an owner. " I think it might be misconception here, the idea you mention is "Whole Value", while Aggregate is more concerned with Transaction Boundary, where all the business invariant rule need to be enforced here. – Billi

To be honest, this sounds like pretty much every project where developers collaborate with architects for more than a month. (Well, according to my experience at least.) Which realization makes me appreciate your answer even more. :) – Pareu

I disagree with the statement that DDD is "only intended for large projects". DDD is nothing you must either do fully or not at all. You can just do some practices from DDD. For example you can just do "Value Objects" and "ubiquitious language" and not do aggregate roots in a small project. – Schaffhausen

Wish that everything would be this logically explained! – Petulancy

" there is a free introduction to DDD available from InfoQ (where you can also find talks about DDD)." Thanks. It's a wonderful read as a whole software development process , not just DDD. – Xanthin

By the way , doesn't we do domain analysis for every project we do or model. Don't we already have never ending conversations as BA with customers and SME's to understand the project domain and scope? I still don't understand what's extraordinarily outstanding in DDD then any other Software development project around? – Xanthin

I have started to use DDD, I was very confused about aggregate. But after your explanation, It will be more easy for me to identify what should be an aggregate root. Thanks a lot – Plonk

What else could drive a design except the domain ? – Luht

Answer 2

Take StackOverflow as an example. Instead of starting to design some web forms, you concentrate first on doing object-oriented modelling of the entities within your problem domain, for example Users, Questions, Answers, Votes, Comments etc. Since the design is driven by the details of the problem domain it is called domain-driven design.

You can read more in Eric Evans' book.

Bawdy

There is a short version of Eric Evans' book available for free. – Camshaft

The problem is you need someone that understand the domain in a abstruct enough way that they can say something useful before they have tied using the web pages! When this is the case greate! – Skyscape

But who would start by designing the form, honestly? Any respectable academic course would go through analysis, design and modeling applications according to business requirements. I just don't get what's new with this technique. – Moleskin

Me too, this is simply an Object Oriented Design, used by everyone even before this concept came. I don't see any new invention here. – Ginn

@RonenFestinger please don't judge DDD by this answer only. There are a lot of insights in the Eric Evans' book. For example bounded contexts. Bounded Context paradigm is one of the pillars of microservices that we are building today. Reading the book also helps you with understanding microservices. – Neddie

@RonenFestinger Have you read any book about DDD to make that judgement? I think that you should read more about it, that may change the way you think about modelling and building complex applications. – Milord

I haven't. But I learned it at work. And read about it on the internet. Can you tell the difference between ddd and non ddd? – Ginn

@troelskn, That short version is of 106 pages itself – Patti

I agree with Ronen Festinger that this answer makes no difference between DDD and our traditional (and maybe the standard way) of designing the system when starting a new project. It's kind of more familiar with the name system analysis and design whose output is a graph of entities and their relationships (usually mapped to tables in a database as well as model classes in our code). We never go from designing some web forms which is terrible, at least designing the UI should be drafted with designing the system at the same time and will be completed later with some possible changes. – Reorganize

@Moleskin they all carry water for their mill and writing books is a business too. The pros are that those who come after are aligned under something respectable and with a certain logic. Armies worked like that since always. The cons are that many believe that if you don't know such a book by such a teacher, then "you don't know anything." This happens with more emphasis in cultures with a cult of the person and mentally highly structured. Cada maestrito con su librito + todos llevan agua para su molino 🤷🏻‍♂️ – Scott