Search code examples
.netlanguage-agnosticoopdomain-driven-designcode-organization

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.


Solution

  • 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.