Como você fator seu domínio (namespaces), em Domain Driven projeto?

Question

Como você fator seu domínio (namespaces), em Domain Driven projeto?

Eu tenho de passar para o seguinte conceito:

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

Por exemplo, eu tenho uma entidade em um CMS chamado "Conteúdo". Então, eu iria criar um projeto chamado Project.Content, e fator de classes para se parecer com:

interface IContent
class Content : IContent

interface IContentRepository
class ContentRepository : IContentRepository

Esta "Conteúdo" modelo de entidade teria seu próprio namespace.

Mas, eu estou achando não escala bem em um ambiente de grande empresa com mais de uma dúzia de projetos (tente 18) de modelos de "entidade". Acabo com uma solução com mais de uma dúzia de projectos, alguns dos quais têm apenas 2 ou 3 classes (i UrlRewriter). Além disso, eu encontro-me referenciando outros projectos apenas para suas interfaces. Eu sinto que esta é poluir meu domínio; enquanto referências não concret, às vezes é difícil manter a partir de referências circulares.

Então, eu cair de volta para o conceito "Layer" às vezes ...

Eu estou querendo saber como outros especialistas DDD são aplicações Enterprise-size factoring. Sinta-se livre para recomendar livros e artigos.

E obrigado antecipadamente!

Answer 1

Um pensar que eu faço é para adicionar algo que identifica o contexto limitado a ele.

Ps. Para se certificar de que está claro porque, verifique ambos os links no contexto limitada: http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html , http://devlicio.us/blogs/casey/ Arquivo / 2009/02/11 / ddd-delimitada-contexts.aspx

Answer 2

Eu uso seguir as orientações .NET . Eu encontrá-los muito intuitivo e eles permitem que você namespaces configuração de tal forma que você não precisa importar qualquer coisa que você não precisa.

Eu nunca iria impor uma convenção de nomenclatura estrita para o nível de recurso. O projeto de cada projeto diferente deve orientar isso.

Answer 3

I de modo semelhante a você descobriu que ter carga de projetos torna-se uma dor de gerir. Eu prefiro o

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

configuração.

De certa forma fazendo as coisas simples ajuda muito quando as coisas vão mal.

A questão é o que você ganha quando você cria outro projeto? (É muito fácil fazê-lo, quase fácil)

Será que você vai querer usar esse projeto de forma independente ou não? Você pode acabar com as .dlls resultantes, de modo juntamente você não pode mesmo implantá-los sem ser exatamente as mesmas versões etc., nesse caso, há pouca razão para dividir-lo e bagunçando seu IDE)

Você sempre pode mudar as coisas para um novo projeto mais tarde, se for necessário, é um pouco doloroso, mas pelo tempo que você teria uma boa razão para fazê-lo para além de apenas a sensação de que é a forma como é feito.