Organizing Namespaces with DDD

About a week ago I posted a message to the Yahoo DDD group to see how other people were organizing their namespaces in their Domain Model. For the most part everyone had the same basic idea. You can read the message here.

In the domain layer, the general consensus seems to be to organize your namespaces around aggregates and/or entities. Not around lower level ideas like “interfaces”, or “services”. You can do this once you break it out into entities, but the first layer or organization should not be around low level organization. Here is an example of how I would setup namespaces in a Blog engine project. After some refining and trying a couple of different ideas I find that this works best for me.

BlogEngine.Core (root namespace for domain model)

- IPost
- BlogPost
- PodcastPost
- IComment
- Comment BlogEngine.Core.Blog.Exceptions
- BlogNotFoundException
- CommentsNotAllowedException

- BlogRepository

- SomeBlogService

- IUser
- User
- UserDetails

- UserNotFoundException

- UserAuthenticationService

And so on. This gives you a nice clear view of your dependencies between aggregates. In each of the User/UserDetails classes, you can clearly see what other aggregates it depends on. I would go even further to say I would seperate interfaces within the aggregate. But this is a task for another day. I would be very interested to hear everyones comments on this. I think everyone uses the same basic ideas but perhaps someone has a better way of doing this that would help enlighten the rest of us =)

About Sean Chambers

I am a Senior software developer from Palm Coast, Florida. An advocate of Domain Driven Design, Behavior Driven Development, creator of FluentMigrator and community activist. I am married to my beautiful wife Erin and am the proud father of two wonderful children. I currently reside at ACI, a local insurance industry/mortgage software company that excels in creating solutions using Agile methodologies.
This entry was posted in ddd. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • This works, just watch out for you modules (bounded context). You can typically refactor towards this later but it gets messy if you are relying on your folder structure to enforce the context boundaries. The context boundaries usually precede any Entity object connotation. You also may have a “Sub Domain” that may precede it as well. Again I wouldn’t worry about this since you can easily refactor towards this, just watch out for your folder structure within your solution.

    Here is my recommended namespace model:

    [ProjectName].[Bounded Context].{Optional Sub Domain}.[DomainEntity/Aggr].[Service/Repository/Factory]

    Does that make sense?

    One other note if I have a new bounded context I usually create a new assembly.

  • I think I follow Joe. I apologize for my relative newbism related to DDD.

    In other words, the namespace organization shouldn’t define boundaries or do you mean something different?

    At the moment my folder structure matches my namespaces.

    One question I just recently asked myself after applying this refactoring is whether my authentication classes should live within my Controllers assembly or my core assembly. The way I did it at the moment is placed the interface within the core, the impl within the controllers assembly and then supply it to the core model at runtime with IoC. Is this not a good thing to do? I may be completely off base here.

    Can you describe more when I should consider creating a new assembly? I suppose my authentication mechanism would be a good candidate?

    Thanks for the info!

  • > I apologize for my relative newbism related to DDD.

    Don’t apologize, I took me 2 years, rereading Evan’s book 3 times making lots of mistakes before I really felt comfortable discussing it with other people.

    >In other words, the namespace organization shouldn’t define boundaries or do you mean something different?

    The exact opposite, they should define “Context Boundaries”. Evan’s refers to this as “Bounded Context” [Evans pg. 335] and may be overkill for most projects but I like to still discuss them because that are the natural evolution of “Modules” [Evans pg. 109].

    Modules offer low coupling between context boundaries and high cohesion within.

    If you think of let say an eCommerce system and you are building an enterprise system I can think of several modules off the top of my head


    As you can see each module has a context that is specific to it’s operation and function within the company. Could each of these be thier own assembly? (Drum role) It depends, on a large scale enterprise application there can be multiple development teams working on each bounded context. Which would warrant multiple assemblies being developed. If there isn’t multiple development teams then best judgment should be utilized. If one of the context boundaries begin to grow out of control consider moving it to its own assembly and distill accordingly.

    The way you would further insure that you adhered to low coupling between each context is utilize an Anti Corruption Layer between each context. [Evans pg. 364]

    >…whether my authentication classes should live within my Controllers assembly or my core assembly.

    OK this is where I get kind of Anal. LOL Stop thinking like a developer! Hard to do, trust me I know.

    Let’s assume that you have a domain expert that you are working with in creating your application. It is important that you and the domain expert form a “ubiquitous language”. Is the “authentication” class an entity or a service? From a domain perspective does the product owner even understand what you mean by authentication service or is it a module that exist within the domain where within the authentication module there is a authenticationService that accepts a Credential value object and returns a User entity? ” The important concept here is agreement by both you and your domain expert on ALL of the domain concepts.

    If you are the domain expert than put on your product owner hat and explain in English what the objects are called from a product owner perspective.

    By far this is the most difficult part of teaching DDD to developers. They immediately starting thinking in design patterns.

    To get a better understanding of what I mean read this post on my blog.

    Hope this helps.

  • What benefit are you gaining by using interfaces for your domain entities?

    I’ve never seen a need to mock these, so I’m wondering what value you’re getting out of them.

  • @Ben, are you referring to IUser, IComment and IPost?

    IUser I mock quite a bit in the tests, in addition to exposing the interface to my controllers assembly. IComment is a bad example because I actually no longer am using that.

    IPost was made to mock posts attached to users and websites.

    All in all, not that many entities implement interfaces. Once a couple of them got quite complex I refactored to interfaces to minimize coupling, seemed to work alright for the time being.

  • IUser I definitely see.

    I’d be suspicious of why you couldn’t just construct your scenario using real objects, so IPost just seems to stand out as weird to me. Maybe a sign that it has too much responsibility, I don’t know.

    I see what you mean. You aren’t just blindly creating interfaces for all your domain classes just for the sake of having interfaces. :)

  • Actually when I first made IPost it was quite awhile ago. I launched this CMS for my work and at the time they needed the blog post aspect right away. I hastily tested it, coded it and published it to our production server and then began work on the rest of the app.

    Now I finally have a chance to go back and do some quality refactorings on this kind of stuff, hence the namespaces and also elimited unnecessary interfaces. IPost is definately a good candidate =)

    the funny part is it doesn’t have many responsibilites at all. i think i smell something =)

  • Joe,

    I ordered Eric Evans book yesterday on Amazon. I couldn’t hold back any longer =)

  • My only recommendation is study it like you are a taking a course on it. You can’t read it like other technical material. Each chapter builds on the other. I hate to say this but every time I reread a chapter I gain new incite.

    Nillson’s books is close but it only scratches the surface of what you are about to learn.

    Good luck.

  • thanks joe.

    the only thing that stinks is amazon says it will be 3 weeks before they can ship it out =(

    oh well.

  • Sean,

    This version can hold you over in the meantime:

    The e-book is a summarized version of the Evans book.

    I’m on my third reading of the Evans book and as Joe said, I’m always learning something new as well (although I’m way behind Joe’s level of understanding).

  • I am also re-reading the book. I’m on my second round and feel just as “over whelmed” as I did on my first. The only other book that has had this much information in it has been the bible. No religous comparison there, well, maybe. If we all just adhered to Evan’s book, bliss and happiness would overwhelm the software industry and there would 1000 years of peace. :)