Meilleure pratique pour appliquer la conception guidée par domaine dans .NET?

Question

J'ai essayé d'apprendre et d'appliquer le concept conduit par domaine dans mon développement de logiciel. La première chose que j'essaie de faire est de créer mon modèle de domaine en fonction des besoins de la logique métier. J'utilise souvent aussi l'outil OR Mapping, tel que LLBLGen, NHibernate ou Linq to SQL, pour créer un modèle de données et une couche d'accès aux données. Le modèle de domaine et le modèle de données, cependant, sont souvent très similaires, ce qui me fait me demander quel est le bénéfice que j'obtiens en maintenant deux modèles. Est-ce que quelqu'un peut partager ses réflexions pratiques sur la conception axée sur le domaine? En outre, comment traiteriez-vous le modèle de données ou la couche d'accès aux données lors de l'application de DDD dans votre application?

Merci d'avance.

EDIT

trouvé un bon article, avec le code exemple, à propos de Pattern Repository.

Answer 1

Je résume mon accès aux données via le modèle Repository, donc gardez mes objets de domaine complètement POCO et agnostique de fournisseur de données. Cela me permet de sculpter mon application du point de vue du domaine, en me concentrant sur la logique, principalement via les tests unitaires. Une fois cela réglé, je mets la couche Présentation (généralement des pages web), puis je valide le schéma de la base de données concrète. J'implémente alors mes classes concrètes de Repository, qui peuvent être L2S.

J'ai rédigé quelques articles ici - http://www.duncangunn.me.uk/dasblog/2009/04/11/TheRepositoryPattern.aspx http://www.duncangunn.me.uk/dasblog/2009/06/27/MockingLinqToSQLRepositories.aspx

Gardez un oeil sur les deux prochaines semaines que je documentera et en fournissant le code de mon exemple d'implémentation qui utilise l'unité de modèle de travail aussi .

Answer 2

Nous mappons les objets de domaine directement à la base de données, ce qui signifie que nous n'avons pas de couche séparée pour l'accès aux données, et que nous traitons plutôt cela comme du code d'infrastructure. Nous utilisons Fluent NHibernate pour la plupart de la configuration.

Answer 3

La séparation de contextes bornés est également un gros avantage DDD, vous résolvez chaque problème dans son contexte, même si vous devez dupliquer les données entre les contextes.

Une bonne définition des racines agrégées donne une conception plus simple et conduit à une amélioration potentielle des performances (évolutivité via le calcul de grille, voir Gojko Adzic post). Lorsque votre conception devient vraiment orientée domaine, vos applications sont plus souples aux nouveaux besoins de l'entreprise, car l'implémentation devient vraiment un détail d'implémentation.