DDDBlog Implementation. Part 1

Posted in DDD
This post has been read 14335 times

In my pervious posts, I wrote about the aspects of TDD and DDD a bit, and following up on the series, I will start building the sample application from this post onwards. For the lack of better name, I will be calling the application DDDBlog.

Setting up the project

Lets create the project structure as shown below.


DDDBlog.Domain : Domain layer is where the Plain-Old CLR Objects reside. These POCOs are entities that form the domain objects for our project. This layer would also contain the repository interface declarations for the domain objects. From a DDD perspective, the Domain layer should be unaware of persistence ( Persistence Ignorance ), so this layer will not have references to the Persistence layer

DDDBlog.Infrastructure : Infrastructure layer provides the bridging for other layers involved in the application. This layer will be used by all other layers. This layer would contain all the base classes required for all other projects. This layer would also define the top level repository interface. I am not sure where the mapping files should fall under this layer or the persistence layer, but for now I think I will go with this layer.

DDDBlog.Persistence :  This layer would contain the actual data access code. Here I will write the actual implementations for the repositories.

DDDBlog.Tests : This layer consists all the tests for all the layers. Its not necessary for us to have single test layer. We can add individual test layer for each of the layers in our application. I however am going with a single test layer.

DDDBlog.Web : This is the web presentation layer for our application.

Tools and libraries used

ASP.NET MVC – Used for the presentation layer. I had thoughts of using Monorail, but preferred ASP.NET MVC as it has come a long way from the CTP’s and I think its pretty good as of now.

NHibernate and FluentNHibernate – These are used for persistence and for the mappings.

StructureMap – This is used for Dependency Injection.

xUnit.Net – This is used for unity testing.

MoQ – This is used for mocking.

In this post we have seen how to layer our application and the tools/libraries that’s needed for our project. In my next post we’ll start coding the base classes for our application.

Comment posted on Tuesday, April 07, 2009 9:20 PM
What's up with all the separate projects? Does each of them represent a deployable unit? Or why do they exist?

(At the corp where i work now they have it this way because it enforces the layering a bit more, eg: not using persistence implementation, or any other resource for that reason, in the domain. But i'm not convinced that is a good enough reason).
Comment posted on Tuesday, April 07, 2009 9:43 PM

For me its mainly for maintainability and understandability in the sense that, to add some functionality i dont have to go through code that's out of concern. Yes you can segregate the functionality into different folders in a single assembly, but when you are testing, the whole assembly is referenced which becomes a pain.

Dont you think its more intuitive when we seperate the functionality into layers?

According to Evans [ DDD ], the principle of layering is that any given element in a layer depends only on elements within the layer or the elements in a layer beneath it.
Comment posted on Wednesday, April 08, 2009 5:23 PM
Who is your domain expert?
Comment posted on Wednesday, April 08, 2009 6:37 PM

Me actually :). The whole idea of this series is to learn DDD, and I developed a blog engine running this site. So i am trying to learn DDD by developing a blog engine based on that.

Any feedback would be appreciated though.
Comment posted on Wednesday, April 08, 2009 8:15 PM
My main feedback would be that a DDD example done without an external domain expert probably isn't a good idea. A few of us have tried this over the years and decided it wasn't a great idea, I'd at the least indicate your using *some* of the patterns from DDD but not others (including the working with domain experts) and that this isn't necessarily the sort of problem that suits a full DDD approach:

Comment posted on Wednesday, April 08, 2009 8:31 PM

Thanks for the feedback. Maybe the whole idea of learning DDD through a blog engine was not right.

But I do like the idea of DDD. Could you suggest me on how to go about learning it from an implementation perspective.
Comment posted on Wednesday, April 08, 2009 8:36 PM

I saw this blog post [ http://nathan.whiteboard-it.com/archive/2009/03/01/asp.net-mvc-domain-driven-design.aspx ] and thought even i could give it a try. But it seems that a blog engine doesn't fit in very well. My bad....
Comment posted on Wednesday, April 08, 2009 8:47 PM
I don't think it suits full DDD no, because you need domain experts and a complex enough problem domain to justify it. Doesn't mean you shouldn't do an example of the patterns and continue on as you are. If you learn from it and teach others then superb, however I'd just make sure to metnion that DDD is about more than the patterns (repository/aggregate/value object/specification/service) and related technologies/practices (ORMs/TDD/POCO) that most people use.

On learning, I'd read Evans book, its superb and defines DDD in depth. There are other resources including the InfoQ book. If you've also gotten your head around POCO/ORMs and related ideas then I'd do exactly what your doing and/or ask questions on the DDD newsgroup: