DDD - modèle de persistance et modèle de domaine

j'essaie d'apprendre le design piloté par domaine (DDD), et je pense que j'ai eu l'idée de base. Mais il y a quelque chose de déroutant moi.

dans le DDD, le modèle de persistance et le modèle de domaine sont-ils différents? Je veux dire, nous concevons notre domaine et nos classes avec seulement des préoccupations de domaine à l'esprit; c'est bon. Mais après cela, lorsque nous construisons nos dépôts ou tout autre système de persistance des données, devrions-nous créer une autre représentation de notre modèle à utiliser dans la couche de persistance?

je je pensais que notre modèle de domaine est aussi utilisé dans la persistance, ce qui signifie que nos dépôts renvoient nos objets de domaine à partir de requêtes. Mais aujourd'hui, j'ai lu ce post, et je suis un peu confus:

Arrêter Ça! Le Modèle De Domaine N'Est Pas Le Modèle De Persistance

si c'est vrai, quel serait l'avantage d'avoir des objets persistence séparés des objets domain?

39
demandé sur Peter Mortensen 2012-12-24 23:08:58
la source

3 ответов

pensez-y simplement de cette façon, le modèle de domaine devrait être dépendant de rien et n'avoir aucun code d'infrastructure dedans. Le modèle de domaine ne doit pas être sérialisable ou hériter de certains objets ORM ou même les partager. Il s'agit là de problèmes d'infrastructure qui devraient être définis séparément du modèle de domaine.

mais, c'est-à-dire si vous êtes à la recherche d'un DDD pur et que votre projet valorise l'évolutivité et la performance par rapport à la vitesse de développement initiale. Plusieurs fois, mélange les problèmes d'infrastructure avec votre "modèle de domaine" peuvent vous aider à faire de grands pas en vitesse au prix de l'évolutivité. Le fait est, vous devez vous demander, "les avantages de DDD pur vaut-il le coût dans la vitesse de développement?". Si votre réponse est oui, alors voici la réponse à votre question.

commençons par un exemple où votre application commence avec un modèle de domaine et il se trouve que les tables dans la base de données correspondent exactement à votre modèle de domaine. Maintenant, votre application se développe à pas de géant et vous commencez à éprouver des problèmes de performance en interrogeant la base de données. Vous avez appliqué quelques index bien pensés, mais vos tables grandissent si rapidement qu'il semble que vous pourriez avoir besoin de dés-normaliser votre base de données juste pour suivre. Donc, avec l'aide d'un dba, vous arrivez avec un nouveau design de base de données qui va gérer vos besoins de performance, mais maintenant les tables sont très différentes de la façon dont elles étaient avant et maintenant morceaux de vos entités de domaine sont répartis sur plusieurs tables plutôt que d'être une table pour chaque entité.

ce n'est qu'un exemple, mais il démontre pourquoi votre modèle de domaine doit être séparé de votre modèle de persistance. Dans cet exemple, vous ne voulez pas séparer les classes de votre modèle de domaine pour faire correspondre les changements que vous avez apportés à la conception du modèle de persistance et essentiellement changer la signification de votre modèle de domaine. Au lieu de cela, vous voulez changer la correspondance entre votre nouveau modèle de persistance et le modèle de domaine.

il y a plusieurs avantages à garder ces conceptions séparées telles que l'évolutivité, la performance et le temps de réaction aux changements de db d'urgence, mais vous devriez les peser par rapport au coût et à la vitesse de développement initial. En général, les projets qui bénéficieront le plus de ce niveau de séparation sont des applications à grande échelle.

UPDATE FOR COMMENTATEURS

Dans le monde du développement logiciel, il est Nième nombre de solutions possibles. Pour cette raison, il existe une relation inverse indirecte entre la flexibilité et la vitesse initiale de développement. Comme un exemple simple, je pourrais code logique dur dans une classe ou je pourrais écrire une classe qui permet des règles de logique dynamique pour être passé dans elle. La première option aurait une plus grande vitesse de développement, mais au prix d'un moindre degré de flexibilité. Cette dernière option offrirait un degré de flexibilité plus élevé, mais au prix d'une la vitesse de développement. Ceci est vrai pour chaque langage de codage, car il y a toujours un nième nombre de solutions possibles.

de nombreux outils sont disponibles qui vous aideront à augmenter votre vitesse de développement initial et la flexibilité. Par exemple, un outil ORM peut augmenter la vitesse de développement de votre code d'accès à la base de données tout en vous donnant la flexibilité de choisir les implémentations spécifiques de base de données que L'ORM prend en charge. De votre point de vue, il s'agit d'un gain net dans les deux temps et de flexibilité, moins le coût de l'outil (certains sont gratuits) qui peut ou peut ne pas être la peine à vous en fonction du coût de temps de développement par rapport à la valeur du besoin de l'entreprise.

mais, pour cette conversation dans les styles de codage, ce qui est essentiellement ce que le Design piloté par domaine est, vous devez tenir compte du temps qu'il a fallu pour écrire cet outil que vous utilisez. Si vous deviez écrire cet outil ORM ou même écrire votre logique d'accès à la base de données de telle sorte qu'il supporte tous les implémentations que l'outil vous donne, cela prendrait beaucoup plus de temps que si vous deviez simplement coder la mise en œuvre spécifique que vous prévoyez d'utiliser.

en résumé, les outils peuvent vous aider à compenser votre propre temps de production et le prix de la flexibilité, souvent en distribuant le coût de ce temps à tous ceux qui achètent l'outil. Mais, tout code incluant le code qui utilise un outil, restera affecté par la relation vitesse/flexibilité. De cette façon, la conception par Domaine permet plus de flexibilité que si vous enchevêtriez la logique de votre entreprise, l'accès à la base de données, l'accès aux services et le code D'assurance-chômage, mais au prix du temps à la production. La conception par Domaine sert mieux les applications au niveau de l'entreprise que les petites applications parce que les applications au niveau de l'entreprise ont tendance à avoir un coût plus élevé pour le temps de développement initial par rapport à la valeur de l'entreprise et parce qu'elles sont plus complexes, elles sont également plus sujettes au changement nécessitant une plus grande flexibilité à un moindre coût. coût dans le temps.

45
répondu Aaron Hawkins 2014-06-14 02:09:53
la source

dans le DDD, le modèle de persistance et le modèle de domaine sont-ils différents?

Oui, mais cela n'implique pas nécessairement un ensemble différent de classes pour représenter explicitement le modèle de persistance.

si on utilise une base de données relationnelle pour la persistance, un ORM tel que le NHibernate peut prendre soin de représenter le modèle de la persistance par des correspondances à des classes de domaines. Dans ce cas, il n'existe pas de classes de modèles de persistance explicites. Le succès de cette approche cela dépend des capacités de cartographie de l'ORM. NHibernate, par exemple, peut supporter une classe de cartographie intermédiaire par composant mappages. Cela permet d'utiliser une classe de modèle de persistance explicite lorsque le besoin s'en fait sentir.

si l'on utilise une base de données de documents pour la persistance, il est généralement encore moins nécessaire d'avoir un modèle de persistance puisque le modèle de domaine ne doit être sérialisable que pour être persistant.

par conséquent, utilisez une persistance explicite classe de modèle lorsqu'il y a une cartographie complexe qui ne peut être atteinte avec les mappages ORM au modèle de domaine. La différence entre le modèle de domaine et le modèle de persistance demeure sans égard à la mise en œuvre.

11
répondu eulerfx 2012-12-24 23:44:02
la source

dans le DDD, le modèle de persistance et le modèle de domaine sont-ils différents?

en DDD vous avez le modèle de domaine et dépôt. Thats it. Si à l'intérieur du dépôt vous persistez votre modèle de domaine directement ou le convertissez en un modèle de persistance avant de persister, c'est à vous de décider! C'est une question de design, votre design.

comme d'autres aswers l'ont indiqué, chaque option a ses avantages et ses inconvénients. Jetez un oeil à ce réponse où j'en détaille certains.

9
répondu fabriciorissetto 2017-05-23 15:32:35
la source