In che modo fattore il tuo dominio (spazi dei nomi) in Domain Driven Design?

Question

In che modo fattore il tuo dominio (spazi dei nomi) in Domain Driven Design?

Mi sono spostato sul seguente concetto:

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

Ad esempio, ho un'entità in un CMS chiamato "Contenuto". Quindi, vorrei creare un progetto chiamato Project.Content e considerare le classi come:

interface IContent
class Content : IContent

interface IContentRepository
class ContentRepository : IContentRepository

Questo " Contenuto " Il modello di entità avrebbe un proprio spazio dei nomi.

Ma sto scoprendo che non si adatta bene in un grande ambiente aziendale con oltre una dozzina di progetti (prova 18) di " Entità " Modelli. Finisco con una soluzione con oltre una dozzina di progetti, alcuni dei quali hanno solo 2 o 3 classi (cioè UrlRewriter). Inoltre, mi ritrovo a fare riferimento ad altri progetti solo per le loro interfacce. Sento che questo sta inquinando il mio dominio; pur non essendo riferimenti concreti, a volte è difficile evitare riferimenti circolari.

Quindi, torno al " Layer " concetto a volte ...

Voglio sapere come altri esperti DDD stanno prendendo in considerazione applicazioni di dimensioni Enterprise. Non esitate a raccomandare libri e articoli.

E grazie in anticipo!

Answer 1

Si pensa che io debba aggiungere qualcosa che identifica il contesto limitato ad esso.

Ps. per accertarti che sia chiaro il perché, controlla entrambi i collegamenti in un contesto limitato:    http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html , http://devlicio.us/blogs/casey/ archive / 2009/02/11 / ddd-delimitata-contexts.aspx

Answer 2

Uso seguire le Linee guida .NET . Li trovo molto intuitivi e ti consentono di impostare spazi dei nomi in modo tale che non sia necessario importare nulla di cui non hai bisogno.

Non importerei mai una rigida convenzione di denominazione per il livello di funzionalità. Il design di ogni diverso progetto dovrebbe guidarlo.

Answer 3

Analogamente a te ho scoperto che avere un carico di progetti diventa un problema da gestire. Preferisco il

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

configurazione.

In un certo senso rendere le cose semplici aiuta molto quando le cose vanno male.

La domanda è cosa guadagni quando crei un altro progetto? (è molto facile farlo, quasi troppo facile)

Vuoi mai usare quel progetto in modo indipendente o no? Potresti finire con le DLL risultanti così accoppiate che non puoi nemmeno distribuirle senza essere esattamente le stesse versioni ecc. In quel caso ci sono poche ragioni per dividerlo e ingombrare il tuo IDE)

Puoi sempre spostare le cose in un nuovo progetto in un secondo momento se se ne presenta la necessità, è piuttosto doloroso, ma a quel punto avresti una buona ragione per farlo a parte la sensazione che è così.