How do YOU factor your Domain (namespaces), in Domain Driven Design?

How do YOU factor your Domain (namespaces), in Domain Driven Design?

I have been moving to the following concept:

Project.Entity
  Project.Entity.Abstracts
  Project.Entity.Entities
  Project.Entity.Extensions
  Project.Entity.Immutables
  Project.Entity.Interfaces
  Project.Entity.Repositories

For example, I have an entity in a CMS called "Content". So, I would create a project called Project.Content, and factor the classes to look like:

interface IContent
class Content : IContent

interface IContentRepository
class ContentRepository : IContentRepository

This "Content" Entity model would have its own namespace.

But, I am finding it does not scale well in a large Enterprise environment with well over a dozen projects (try 18) of "Entity" models. I end up with a solution with over a dozen projects, some of which only have 2 or 3 classes (i.e. UrlRewriter). Also, I find myself referencing other projects just for their Interfaces. I feel like this is poluting my domain; while not concret references, it's sometimes difficult to keep from circular references.

So, I fall back to the "Layer" concept at times...

I am wanting to know how other DDD experts are factoring Enterprise-size applications. Please feel free to recommend books and articles.

And thanks in advance!

From stackoverflow

• I use follow the .NET guidelines. I find them very intuitive and they allow you to setup namespaces such that you don't need to import anything you don't need.

  I would never impose a strict naming convention for the feature level. The design of each different project should guide that.

• One think that I do is to add something that identifies the bounded context to it.

  Ps. to make sure it is clear why, check both links on bounded context: http://domaindrivendesign.org/discussion/messageboardarchive/BoundedContext.html, http://devlicio.us/blogs/casey/archive/2009/02/11/ddd-bounded-contexts.aspx

  eduncan911 : Corrected link: http://devlicio.us/blogs/casey/archive/2009/02/11/ddd-bounded-contexts.aspx

• I similarily to you have found out that having load of projects becomes a pain to manage. I prefer the

  Project.Domain
  Project.DataAccess
  Project.Presentation (presenters and such) 
  Project.Gui (in case of a winforms app)
  

  setup.

  In a way making things simple helps a lot when things go bad.

  The question is what do you gain when you create another project ? (it is very easy to do so, almost to easy)

  Will you ever want to use that project independently or not ? You might end up with the resulting .dlls so coupled you can't even deploy them without being exactly the same versions etc. in that case there is little reason for splitting it up and cluttering your IDE)

  You can always move things to a new project later if the need arises, it is somewhat painfull, but by that time you would have a good reason to do it apart from just the feeling that is the way it is done.

  eduncan911 : I like your thought of "Will you ever want to use that project independently or not?" This strikes are the core architecture design thoughts; and, it may be exactly what I was looking for. Let me review the other's links before voting the answer. Thanks!

  Tomas Pajonk : I have unfortunately been on the route of too many projects and I just gets so messy ...