308

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?

halfer
  • 19,824
  • 17
  • 99
  • 186
YodasMyDad
  • 9,248
  • 24
  • 76
  • 121

2 Answers2

687

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).

Sebas
  • 21,192
  • 9
  • 55
  • 109
Rob Knight
  • 8,624
  • 1
  • 20
  • 11
  • 43
    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. – YodasMyDad Aug 03 '09 at 18:48
  • 4
    "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. – super1ha1 Jun 01 '17 at 08:41
  • 7
    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. :) – Jaroslav Záruba Jun 02 '17 at 05:37
  • 4
    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. – EasterBunnyBugSmasher Sep 28 '17 at 06:57
  • 1
    Wish that everything would be this logically explained! – Elz Oct 11 '17 at 15:51
  • " 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. – supernova Nov 06 '17 at 00:47
  • 9
    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? – supernova Nov 06 '17 at 01:39
  • 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 – JessGabriel Jun 26 '19 at 12:41
  • What else could drive a design except the domain ? – Angle.Bracket Apr 13 '21 at 13:38
58

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.

Matt Howells
  • 40,310
  • 20
  • 83
  • 102
  • 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!** – Ian Ringrose Feb 07 '11 at 14:16
  • 7
    There is a short version of Eric Evans' book [available for free](http://www.infoq.com/minibooks/domain-driven-design-quickly). – troelskn Aug 03 '09 at 13:40
  • 6
    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. – Sebas Dec 08 '16 at 11:16
  • 7
    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. – Ronen Festinger Apr 21 '17 at 09:42
  • 2
    @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. – Kerem Baydoğan Apr 10 '18 at 19:03
  • @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. – Daniel Botero Correa Apr 13 '18 at 10:11
  • 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? – Ronen Festinger Apr 15 '18 at 10:13
  • 1
    @troelskn, That short version is of 106 pages itself – Hamza Khanzada Nov 28 '19 at 10:28
  • 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. – Hopeless Jul 24 '20 at 18:47
  • @Sebas 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 ‍♂️ – zurcacielos Mar 14 '23 at 06:20