Comment VOUS factorisez votre domaine (espaces de noms), dans la conception dirigée par le domaine?

Question

Comment prenez-vous en compte votre domaine (espaces de noms) dans la conception dirigée par le domaine?

Je suis passé au concept suivant:

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

Par exemple, je possède une entité dans un CMS appelée "Contenu". Donc, je créerais un projet appelé Project.Content et donnerais aux classes l’apparence suivante:

interface IContent
class Content : IContent

interface IContentRepository
class ContentRepository : IContentRepository

Ce " Contenu " Le modèle d'entité aurait son propre espace de noms.

Toutefois, j’ai constaté qu’il n’évolue pas correctement dans un environnement de grande entreprise comptant plus d’une douzaine de projets (essayez 18) de "Entity". des modèles. Je me retrouve avec une solution avec plus d’une douzaine de projets, dont certains n’ont que 2 ou 3 classes (par exemple, UrlRewriter). De plus, je me retrouve à référencer d'autres projets uniquement pour leurs interfaces. J'ai l'impression que cela est en train de polluer mon domaine; Bien qu'il ne s'agisse pas de références concrètes, il est parfois difficile d'éviter les références circulaires.

Je tombe donc dans la "couche" concept parfois ...

Je souhaite savoir comment d'autres experts de DDD factorisent des applications de taille entreprise. N'hésitez pas à recommander des livres et des articles.

Et merci d'avance!

Answer 1

Ce que je pense, c’est d’ajouter quelque chose qui identifie le contexte délimité.

Ps. Pour vous assurer qu'il est clair pourquoi, vérifiez les deux liens sur le contexte délimité:    http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html , http://devlicio.us/blogs/casey/ archive / 2009/02/11 / ddd-bounded-contexts.aspx

Answer 2

J'utilise les consignes .NET . Je les trouve très intuitifs et vous permettent de configurer des espaces de noms de sorte que vous n’ayez pas besoin d’importer ce dont vous n’avez pas besoin.

Je n'imposerais jamais de convention de dénomination stricte pour le niveau de fonctionnalité. La conception de chaque projet différent devrait guider cette démarche.

Answer 3

De la même manière, vous avez découvert qu'avoir beaucoup de projets devenait difficile à gérer. Je préfère le

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

configuration.

D'une certaine manière, simplifier les choses aide beaucoup lorsque les choses tournent mal.

La question est de savoir ce que vous gagnez lorsque vous créez un autre projet. (il est très facile de le faire, presque trop facile)

Voulez-vous un jour utiliser ce projet de manière indépendante ou non? Vous pourriez vous retrouver avec les fichiers .dll résultants, de sorte que vous ne pouvez même pas les déployer sans être exactement les mêmes versions, etc. Dans ce cas, il n'y a aucune raison de le scinder et d'encombrer votre environnement de développement).

Vous pouvez toujours déplacer des éléments vers un nouveau projet ultérieurement si le besoin s'en fait sentir, mais c'est un peu pénible, mais à ce moment-là, vous aurez une bonne raison de le faire, mis à part le simple sentiment que c'est comme ça que ça se passe.