Guidelines for solution source code organisation(OO/DDD)

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.

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.

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