Domain Driven Design: Learning

1.  Introduction

In the post I would like to help folks who want to improve their design skills and way of thinking by introducing in the Domain Driven Design (DDD) and provide a set of resources which I find useful. Also I will try to sort the resources because very often we can drop to learn something new only because we don’t see any sense or very little sense in reading a topic. That can happen because some resources are good for beginners other are good for more advanced folks, some persons need more practical examples for others  theory is enough to create a picture.

2.Why DDD?

There are few patterns to organize Domain Logic (or business logic):

1)      Table Module - A single instance that handles the business logic for all rows in a database table or view.

2)      Transaction Script - Organizes business logic by procedures where each procedure handles a single request from the presentation.

3)      Domain Model - An object model of the domain that incorporates both behavior and data.

The patterns are described in more depth in Patterns of Enterprise Application Architecture (P of EAA) book by Martin Fowler. In his book he shows that first two patterns are easier to start with than Domain Model pattern, but by adding more complexity to domain logic, time to implement the complexity is much smaller when Domain Model is used. So the short conclusion from this is that Domain Model pattern is well suited to challenge complex domain needs (e.g. Financial Domains). Most of the software solutions in nowadays are designed to automate different domains, and a large number of systems are specific to particular needs of a business, so common software solutions in high competitive business less and less find their place in market. Why I’m discussing that? Because DDD is not only about the pure design but also teach how to abstract a complex Domain in a software solution where you will discover new ways of dealing with complexity, changes, communication, ubiquitous language etc.. Instead of making the system ugly, very hard to understand, un-maintainableand where any change in the system leads to a deeper legacy.

DDD doesn’t ignore any other existing practice: Object Oriented Design, GoF patterns, S.O.L.I.D. design principles, TDD, Agile etc… DDD just complements them. To find right model and abstractions in complex scenarios still is needed to be a good Object Oriented modeler using various patterns and principles (not just DDD’s).

3.       Where to start from?

If you were interested in my DDD commercial then let’s go further, if not but still want to know more about DDD don’t leave the post because you can find more information interesting in provided resources :-).

 First book which puts the light on DDD for larger community was Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. The book describes very well what DDD is about and all aspects such as: ubiquitous language, bounded context, patterns, design best practices, refactoring, domain modeling, how it works in Agile, and a lot of other good things. But even you will understand all very well what is described in the book which is not easy task, but… the book could leave a lot of questions from practical perspective (how those things works in practice) because the book is technology - agnostic. That can’t happen for advanced developers with strong background. For most of us reading theory without seeing a practical part of the things is very boring and even could lead to confusions. That is why I would recommend starting with a mini version of the Eric’s book, Domain Driven Design Quickly which could be downloaded for free if you have a registration on the infoq site.

There are also good Eric’s presentations which you can start with:

1)      DDD: putting the model to work

2)      Eric Evans on DDD: Strategic Design

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

4)     Strategic Design & Responsibility Traps

Infoq has many other good presentations, articles and interviews.

So if you already have some theoretical background and where interested in the DDD then to clarify practical things of the organization of a software solution checkout .NET Domain-Driven Design with C#, Problem – Design – Solution book by Tim McCarthy.  

From the book you can learn in practice:

1)      How the process is going from requirements to design and then to a code solution

2)      How to organize architectural solution and layers

3)      How common DDD patterns and practices are applied

4)      How to build a little infrastructure framework for DDD

5)      How to isolate Domain Model from infrastructure

6)      Etc...

This is very good DDD practical book, even there are not ready to use implementations for production, but his ideas and concepts can be applied widely.  The book starts with just requirements and finally at the end of the book the author provides a sample application in .NET 3.5 which you can check out on codeplex.

All the concepts of the book are built mainly on three books: Martin’s PoEAA, Eric’s Book, and Jimmy Nilsson’s book Applying Domain - Driven Design and Patterns.  

However DDD is not only practical solution or patterns, it is a mindset and discipline, and there are many other things which should be considered if you are decided to go on DDD way such as:  focusing on a model and importance of a model, ubiquitous language, bounded context, process of modeling, knowledge sharing, refactoring, strategic design, etc... that is why I strongly recommend to return back to the Eric’s book after reading Tim’s book. At the stage Eric’s book will give you more value and more concepts which are better understudied. 

DDD is not tied to any technology however it will be hard to accomplish it without good tools and practices in your toolkit such as TDD, ORM, Persistence Ignorance (PI), Inversion of Control (IoC), and Aspect Oriented Programming (AOP), that doesn’t mean that all of them always are absolutely necessary but they can help to implement a real DDD solution. Particularly those tools can help to isolate domain model from infrastructure, the isolation is a key of success in DDD. Nilsson’s book covers those tools and techniques that are practical guide to implement maintainable and robust DDD systems. Nilsson also shows how to link enterprise patterns and DDD concepts in one well structured system in the same time showing how modern technologies and techniques can be useful rather an obstacle.

4.       DDD related topics

Other very tightly related topic is Distributed DDD (DDDD). DDDD is DDD in distributed scenarios.  There are not so many resources on the DDDD, in few words DDDD is about messaging and Domain Driven Design, Command Query Separation (CQS) concept helps to combine DDD and messaging. Greg Young says that he is writing a book related to DDDD. More theory about CQR here and sample here .

SOA and DDD is also another great topic which is very often discussed by Udi Dahan

5.       DDD patterns, concepts and terms

In real world DDD implementation are used a set of patterns, a part of them are described in Eric’s book, but as I already mentioned that doesn’t mean other OO principles and pattern are not applicable, such as GoF patterns,  PoEAA, Enterprise Integration Patterns, etc…

Here are few of them:

a)      Value Object

b)      Entity

c)       Service

d)      Module

e)      Aggregate

f)       Repository

g)      Specification

h)      Layer Supertype

i)        Identity Map

j)        Factories

k)      Unit of Work(UoW)

l)        Inversion of Control(IoC)

m)    Aspect Oriented Programming(AOP)

n)      Bounded Context

o)      Ubiquitous language

p)      Object-relational mapping(ORM)

q)      Anemic Domain Model anti pattern

 

6.       Sample applications

Good DDD samples is very hard to find, that is not because they doesn’t exists but because real DDD power is discovered in complex domains. Mostly DDD projects with complex domains are commercial projects. However there are few projects where you can catch some ideas to have implementation view of DDD patterns.

Here are few of them:

1) Tim’s project, the project is described in details by his book. He not only describes patterns used but also a domain model implementation from DDD point of view.

The project is also interesting because he uses new technologies like .NET 3.5, WPF, and shows how to implicate Model View View-Model (MVVM) pattern to adapt domain model to view and take advantage of powerful data binding.  Also I like how he finds common logic and refactor it to Template Pattern.              

2) Next project which I strongly recommend to take a look is Yves Goeleven's sample application; he also has posts where he describes his sample application and DDD concepts. Another his sample application advantage is that the sample is based on his little and clean framework if I can name so. The framework source code is also available. Take attention to how he uses specification pattern together with repositories.

3) Billy McCafferty also has a very interesting open source framework which is focused to DDD, named S#arp Architecture. He also has a very good description of many best practices which are encapsulated by the framework. The framework mainly is targeted to ASP.NET MVC and NHibernate.

4) C# Domain-Driven Design sample application ( ndddsample ), Im also involved in the project, the project is in mature stage, and has a lot of DDD patterns and concepts covered from practical perspective. One of the main targets of the project is to demonstrate a practical implementation of the building block patterns described in the Eric Evans book based on a real but simplified cargo domain (which is also used as example in Eric Evans’ book).

The project is based on a joint effort by Eric Evans' company Domain Language and the Swedish software consulting company Citerus.

The purpose of the project is:

-To show practical side of DDD using .net framework

- Incrementally adjust the code and apply .net conventions and practices

- Use latest .net tools, technologies and software development methodologies that are widely used and discussed within alt.net group

- To provide an "how-to" example for implementing a typical DDD application

- To show a decent way to do it(but not the way to do it). Eventually, the same design could be re-implemented on various popular platforms, to give the same assistance to people working on those platforms,and also help those who must transition between the platforms.

- To support discussion of implementation practices. Variations could show trade-offs of alternative approaches, helping the community to clarify and refine best practices for building DDD applications. 

here is more info.

5) MyShop - DDDD Sample Application - This is a sample application to proof the concept of DDDD, better known as CQS & event storage an extension to DDD. This concept was first mentioned by Gregory Young and since then it created a huge buzz in the community

7.       Domain Driven Design Recommended

Official site - http://domaindrivendesign.org/

Discussion Group - http://tech.groups.yahoo.com/group/domaindrivendesign/ this is very old group, very good source of ideas, place for discussion of all kind DDD related problems. Your question could be answered by many experienced in DDD people, even by Eric Evans :-).

Jimmy Bogard - http://www.lostechies.com/blogs/jimmy_bogard/default.aspx

Colin Jack - http://colinjack.blogspot.com/

Greg Young - http://codebetter.com/blogs/gregyoung/default.aspx

Casey Charlton - http://devlicio.us/blogs/casey/

Udi Dahan - http://www.udidahan.com/

An Introduction To Domain-Driven Design- http://msdn.microsoft.com/en-us/magazine/dd419654.aspx

 

 

8. Conclusion

If you want to open your Object Oriented horizons in complex enterprise systems and discover new development and design ways then DDD is for you.