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, ubiquities 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: ubiquities 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 patternsPoEAA, 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)      Ubiquities 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.

Thank you,

Artur Trosin

Published Monday, February 09, 2009 4:41 PM by Artur Trosin

Comments

# Domain Driven Design: Learning - Artur Trosin's blog

Monday, February 09, 2009 1:19 PM by DotNetShoutout

Thank you for submitting this cool story - Trackback from DotNetShoutout

# Note to self: read some more about Domain Driven Design

Monday, February 09, 2009 2:51 PM by Remco Ros' blog

Note to self: read some more about Domain Driven Design

# re: Domain Driven Design: Learning

Tuesday, February 10, 2009 3:13 AM by Artur Trosin

Hi Remco,

For me too, because knowledge are always not enough (especially DDD) :).

# Link Listing - February 9, 2009

Tuesday, February 10, 2009 7:22 AM by Christopher Steen

Link Listing - February 9, 2009

# Link Listing - February 9, 2009

Tuesday, February 10, 2009 7:23 AM by Christopher Steen

ASP.NET Thoughts on AJAX Preview 4 and JSINQ [Via: scott ] Podcasts New Spaghetti Code Podcast: VSTS...

# re: Domain Driven Design: Learning

Tuesday, February 10, 2009 10:27 AM by Brian

Great resource!

L) and M) are the same link, M is the incorrect one.

# 关于Domain Driven Desing的两篇简单易懂的文章

Tuesday, February 10, 2009 12:35 PM by new 维生素C.net()

weblogs.asp.net/.../devl...

# re: Domain Driven Design: Learning

Tuesday, February 10, 2009 2:46 PM by Artur Trosin

Hi,

Sorry for inconvenience, links are fixed.

# Dew Drop - February 11, 2009 | Alvin Ashcraft's Morning Dew

Wednesday, February 11, 2009 9:48 AM by Dew Drop - February 11, 2009 | Alvin Ashcraft's Morning Dew

Pingback from  Dew Drop - February 11, 2009 | Alvin Ashcraft's Morning Dew

# re: Domain Driven Design: Learning

Tuesday, March 10, 2009 3:33 AM by manish ranjan sharma

its very good article on Domain Driven Design really very nice to undersatnd..

# re: Domain Driven Design: Learning

Tuesday, April 21, 2009 7:43 PM by Mustafa Bilge

Thank you Arthur, for this great, goal-oriented and covering-whole summary.

# re: Domain Driven Design: Learning

Monday, April 27, 2009 6:41 AM by Tony Burkson

JUNE 2009- SKILLSMATER IS ORGANISING NUMEROUS EVENTS FOR THE DDD community in June.Visit skillsmatter.com/.../tb-38.

Please send us any suggestions of events or topics you would like to be covered. DDD in June is going to see all the experts in DDD congregating in london.

Expect to get the latest DDD lessons directly from the source - Eric Evans, Gojko Adzic, Ian Cooper, Hans Dockter, Alberto Brandolini, Phil Wills and more!

# ???????????? ?????????????????????????? ???? ???????????? ???????????????????? ?????????????? (DDD: Domain Driven Design) « butaji

Pingback from  ???????????? ?????????????????????????? ???? ???????????? ???????????????????? ?????????????? (DDD: Domain Driven Design) « butaji

# Учимся проектировать на основе предметной области (DDD: Domain Driven Design)

Saturday, June 06, 2009 2:58 PM by Vitaly Baum

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся

# Domain-Driven Design: Two basic premises

Tuesday, June 09, 2009 10:41 AM by Artur Trosin's blog

In the post I want to discuss about two basic Domain-Driven Design premises which stand on the base of

# Twitter Trackbacks for Domain Driven Design: Learning - Artur Trosin's blog [asp.net] on Topsy.com

Pingback from  Twitter Trackbacks for                 Domain Driven Design: Learning - Artur Trosin's blog         [asp.net]        on Topsy.com

# re: Domain Driven Design: Learning

Wednesday, December 16, 2009 12:48 PM by Roy

If the Application Layer calls a Domain Service, then shouldn't the Domain Service be a Static Class INSTEAD OF an Interface? I feel if a Domain Service is only an Interface, then that leaves the Application Layer with the responsibility to implement the business rules. I need clarification on this. This is the only aspect of DDD that confuses the hell out of me.

Thanks

# re: Domain Driven Design: Learning

Wednesday, December 16, 2009 3:55 PM by Artur Trosin

@Roy

Service within domain model is an operation that usually doesn’t fit well in any Entity or Value Object. An example is Transfer operation from one account entity to another account entity instance. So, in this case it could be implemented as MoneyTransfer class with the Transfer(Account source, Account destination){…}  method\operation (it could be static or not static class) within domain model.  It is what you suggested.

If you take a look here domaindrivendesign.org/.../125 ,  you will see ‘interface’  term but its meaning not interface keyword but public class members(it is general meaning of interface in OOD).

Also, services in general is recommended to be expose via an interface (i.e. interface IMoneyTransfer{…}).

Hope that’s clarify a bit.

# re: Domain Driven Design: Learning

Thursday, December 17, 2009 10:33 AM by Roy

Thanks for the quick response, Artur. That does clarify a bit. My only question now is if it's recommended that a Domain Service be exposed through an interface, shouldn't that implementation still resided in the Domain vs the Application?

For example: in the namespace Domain.Services you would have IMoneyTransfer and within the same namespace have MoneyTransferService that implements IMoneyTransfer.

Does that make sense?

What I'm getting at is you wouldn't build an Application Service object to implement a Domain Service interface like IMoneyTransfer.

Is that right?

# re: Domain Driven Design: Learning

Friday, December 18, 2009 2:23 AM by Artur Trosin

@Roy

For most cases your logic is right, but...

all the implementation of domain logic should be within domain model, in the same time domain model must not be polluted with any infrastructure logic. As side effect of this if you need to have some external calls to web service for example or imply infrastructure logic in the service operation, then you can have just interface within domain model of the service but implement it within Application layer. Application layer is the only layer where is allowed to mix infrastructure (logging, transactions,…) with domain.

# re: Domain Driven Design: Learning

Friday, December 18, 2009 5:58 PM by Roy

Very interesting. Thanks, Artur.

# re: Domain Driven Design: Learning

Monday, December 28, 2009 6:34 PM by Dennis

Great overview! With this post my interest for DDD has started a few months ago. Here are two sources that I found very usefull after digging through your whole list: domaindrivendesign.org/.../evans_2009_1 and http://myshop.codeplex.com/

# re: Domain Driven Design: Learning

Tuesday, December 29, 2009 2:43 AM by Artur Trosin

@Dennis

Thank you for feedback and links, I've updated the article and referenced them, also are added some new links.

# re: Domain Driven Design: Learning

Thursday, January 07, 2010 9:01 AM by Dennis

Thanks Arthur!

Leave a Comment

(required) 
(required) 
(optional)
(required)