4

I have a copy of Head First Design Patterns and I read through a few of the patterns in there. Now is Domain driven design a substitute to the traditional design patterns or does it build upon it? If its the latter, do I need to be a Design patterns expert before I attempt to learn domain driven design? What is the recommended path to DDD?

Foo
  • 4,206
  • 10
  • 39
  • 54

3 Answers3

6

I read the blue book [Evans], the red book [Vernon] and occasionally pop into this tag on StackOverflow.

The book by Evans is very high level in some aspects and covers more than just code. The book by Vernon covers the building blocks of DDD an item at a time, using examples from a fictitious software product as an example:

Domain-driven Design: Tackling Complexity in the Heart of Software

Implementing Domain-Driven Design

There's also the video:

Eric Evans: What I've learned about DDD since the book

As for design patterns, the DDD material refers to lots of design patterns. Some existing design patterns work very well with DDD. You can pick these up as you encounter them, you wont necessarily need to know them in advance. One thing to avoid when learning design patterns, is to not try and force their use, they have their uses but you see a lot of developers trying to force the use of newly learnt design patterns in places where they aren't required.

Adrian Thompson Phillips
  • 6,893
  • 6
  • 38
  • 69
  • 5
    +1 a lot of the principles in DDD have nothing to do with writing code. – MattDavey Jul 16 '13 at 09:32
  • 1
    There are strategic patterns and tactical patterns in DDD. It's the strategic patterns that are most important; bounded context, ubiquitous language, context maps... The tactical patterns support you in writing code that enable the strategic patterns; design patterns, entities, aggregates, value objects, messaging concepts... Although the Blue Book is a monument, I would start with reading the Red Book to get a practical look at DDD. – JefClaes Jul 17 '13 at 19:36
  • For a mid-level developer with rudimentary design pattern knowledge in a "time is of the essence" scenario, do you recommend starting with Evans' or Vernon's book? – Jacob Stamm Feb 20 '19 at 20:03
  • @JacobStamm most of the design patterns and key parts of DDD are not particularly around writing code. I wouldn't say either book is easily consumable. Maybe the newer Domain-Driven Design Distilled book, also by Vernon might be more what you're looking for? – Adrian Thompson Phillips Feb 22 '19 at 12:11
3

Just do it. Don't let any preconceived condition prevents you from starting to practice it.

Yugang Zhou
  • 7,123
  • 6
  • 32
  • 60
2

This is a bit late answer, but i want to say that patterns are not some set-in-stone follow-to-the-letter ultimate solutions. They are generic approaches to generic problems, guidelines if you want.

In DDD you provide specific solution to specific problems. If you can recognize patterns in your implementation you will gain a bit deeper and more structured understanding. If you can see problems calling for some patterns, you will have possible approaches for solving it. But beware, looking at the problem solely through patterns might lead to suboptimal solutions.

Knowing and understanding patterns will help you convey knowledge about implementation details to other developer in more efficient manner. Like "this is Unit of Work" instead of "this object holds references to objects we act upon in this transaction and tracks their state so we can commit all changes at once".

Other than that, it is more important that you understand and follow SOLID and DDD principles to build successful domain models.

Xerkus
  • 2,695
  • 1
  • 19
  • 32