Guidelines for solution source code organisation(OO/DDD)

Question

I'm starting on my first business project (.NET) and am trying to follow DDD principles. Are there any guidelines or common patterns for orgaining source code and namespaces?

For example, do your domain objects go in a namespace MyProject.Domain or whatever? Would you separate the concrete implementations and the interfaces? In different namespaces? Different folders? Different solutions?

I know a lot of this is subjective and dependent on project size, but a few pointers or suggestions to get started on a relatively small but extensible n-tier project would be useful.

Answer 1

There are many correct ways to organize a DDD application's solution, so be open to experiments. I changed my personal solution layout few times. I think the details depend on technology you use, but overall organization stay quite the same.

• One solution per bounded context
• One Domain project containing the model (entities, value objects, repository interfaces etc.)
• One Domain.Persistence (or DataAccess) project containing NHibernate mappings, repository implementations and NHibernate-specific types. If you have serious plans of having more than one persistence layer, you can name them Domain.Persistence..
• One Application project containing the application layer code (services)
• Any number of UI or Windows Service projects

Take a look at my DDDSample.Net project. It contains many variants of DDD solution for the same problem. I've just described the most typical simple one, but there are more complicated, specifically:

• A model with several layers
• A CQRS system
• An Event Sourcing CQRS system

Hope that helps.

Answer 2

I am new at this as well, but here's what I've done.

The root of our project organization is our company name, call it company. The projects are laid out as follows:

• Company.Core has several namespaces:

  .Data defines interfaces for our DAL

  .Repository defines base-interfaces for our repositories

• Company.Data is a concrete implementation of the DAL

• Company.Domain is the domain objects and where repository interfaces are defined

• Company.Repository is a concrete implementatio of the repositories

• Company.Tests has many namespaces:

  .Data tests the DAL, .Data.Mock mocks it

  .Repository tests the repositories, .Repository.Mock mocks them

  .Domain tests the domain objects using mocked repositories

It's all wired together with AutoFac