Avec tous ces services, comment ne pas être anémique?


90

Où est la limite entre la délégation et l'encapsulation de la logique métier? Il me semble que plus nous déléguons, plus nous devenons anémiques . Cependant, la délégation encourage également la réutilisation et le principe de DRY. Alors, qu'est-ce qui convient de déléguer et que devrait rester dans nos modèles de domaine?

Prenons comme exemple les préoccupations suivantes:

Autorisation . L'objet de domaine doit-il être responsable de la gestion de ses règles de contrôle d'accès (comme une propriété CanEdit) ou doit-il être délégué à un autre composant / service uniquement responsable de la gestion de l'accès, par exemple IAuthorizationService.CanEdit (objet)? Ou devrait-il être une combinaison des deux? Peut-être que l'objet de domaine a une propriété CanEdit qui délègue à un IAuthorizationService interne pour effectuer le travail réel?

Validation . La même discussion que ci-dessus concerne la validation. Qui maintient les règles et qui est chargé de les évaluer? D'une part, l'état de l'objet doit appartenir à cet objet et la validité est un état, mais nous ne souhaitons pas réécrire le code utilisé pour évaluer les règles de chaque objet du domaine. Nous pourrions utiliser l'héritage dans ce cas ...

Création d'objet . Classe d'usine contre méthodes d'usine contre "nouveauté" d'une instance. Si nous utilisons une classe de fabrique séparée, nous pouvons isoler et encapsuler la logique de création, mais aux dépens de l'ouverture de l'état de notre objet à la fabrique. Cela peut être géré si notre couche de domaine se trouve dans un assemblage séparé en exposant un constructeur interne utilisé par l'usine, mais cela devient un problème s'il existe plusieurs modèles de création. Et si l’usine n’appelle que le bon constructeur, à quoi sert-elle d’avoir l’usine?

Les méthodes d'usine de la classe éliminent le problème d'ouverture de l'état interne de l'objet, mais comme elles sont statiques, nous ne pouvons pas rompre les dépendances en injectant une interface de fabrique comme avec une classe de fabrique distincte.

Persistance . On pourrait argumenter que si notre objet domaine doit exposer CanEdit tout en déléguant la responsabilité d'effectuer le contrôle des autorisations à une autre partie (IAuthorizationService), pourquoi ne pas avoir une méthode Save sur notre objet domaine qui répète les mêmes choses? Cela nous permettrait d'évaluer l'état interne de l'objet pour déterminer si l'opération peut être effectuée sans rompre l'encapsulation. Bien sûr, cela nécessite que nous injections l'instance de référentiel dans notre objet de domaine, ce qui sent un peu pour moi. Alors, levons-nous un événement de domaine à la place et permettons à un gestionnaire d'effectuer l'opération de persistance?

Vous voyez où je vais avec ça?

Rockford Lhotka a eu une discussion intéressante sur les raisons pour lesquelles il a choisi la voie de la classe responsable pour son framework CSLA. J'ai un peu d'histoire avec ce cadre et je peux voir son idée d'objets métier en parallèle avec des objets de domaine de plusieurs manières. Mais pour essayer de devenir plus adhérent aux bons idéaux DDD, je me demande quand la collaboration devient trop lourde.

Si je me retrouve avec IAuthorizationService, IValidator, IFactory et IRepository pour ma racine globale, que reste-t-il? Avoir une méthode Publish qui modifie l'état de l'objet de Brouillon à Publié est-il suffisant pour considérer la classe comme un objet de domaine non-anémique?

Tes pensées?


Excellente question. Je n'ai pas de réponse pour vous car je suis presque toujours complètement anémique en conception pour la même raison: utiliser / consommer / exposer des services de / dans de nombreux contextes ou applications différentes.
Hromanko

Excellente question, j'aimerais bien voir onclebob, martinfowler, ericevans et autres à ce sujet. Maintenant pour moi de partir et d’avoir une longue réflexion
Martijn Verburg le

Je me trouve évoluer vers un modèle anémique tout le temps; et donc je me bats avec cette même chose exacte. Bonne question!
L-Four

Cela a également été mon expérience avec DDD. Nous le faisons là où je travaille et nous finissons toujours par devenir anémiques. Auparavant (et j'utilise encore actuellement), j'utilise Csla. Notre architecte n'aime pas que nous soyons anémiques, mais il n'a pas été en mesure de me donner une bonne réponse à ce que l'objet devrait faire si tout ce que vous signalez ne peut pas être fait dans l'objet. En fin de compte, essayer d'être un puriste DDD semble créer plus de travail que sa valeur. Personnellement, je pense que Csla et DDD s'entendent bien (ils semblent identiques en principe), si vous êtes prêt à laisser le dogme DDD derrière vous.
Andy

Voici un exemple de techniques utilisées lors de la modélisation de domaine à partir d'une perspective comportementale (non centrée sur les données): medium.com/@wrong.about/…
Zapadlo

Réponses:


66

La plupart des confusions semblent concerner des fonctionnalités qui ne devraient absolument pas exister dans le modèle de domaine:

  • La persistance ne devrait jamais être dans le modèle de domaine. Plus jamais. C'est la raison pour laquelle vous utilisez des types abstraits, par exemple IRepositorysi une partie du modèle doit faire quelque chose comme récupérer une partie différente du modèle et utiliser l'injection de dépendance ou une technique similaire pour câbler la mise en œuvre. Alors rayez ça du compte rendu.

  • L’autorisation ne fait généralement pas partie de votre modèle de domaine, sauf s’il s’agit bien du domaine, par exemple si vous écrivez un logiciel de sécurité. Les mécanismes permettant de savoir qui est autorisé à exécuter quoi dans une application sont normalement gérés à la "périphérie" du niveau métier / domaine, les parties publiques auxquelles les éléments d'interface utilisateur et d'intégration sont réellement autorisés à parler - le contrôleur dans MVC, les services ou le système de messagerie lui-même dans une SOA ... vous obtenez l'image.

  • Les usines (et je suppose que vous voulez dire des usines abstraites ici) ne sont pas vraiment mauvaises à avoir dans un modèle de domaine, mais elles sont presque toujours inutiles. Normalement, vous n’avez une usine que lorsque les mécanismes internes de la création d’objet peuvent changer. Mais vous n'avez qu'une implémentation du modèle de domaine, ce qui signifie qu'il n'y aura jamais qu'un seul type d'usine qui invoque toujours les mêmes constructeurs et un autre code d'initialisation.

    Vous pouvez avoir des usines "de commodité" si vous le souhaitez - des classes qui encapsulent des combinaisons courantes de paramètres de constructeur - mais honnêtement, d'une manière générale, si vous avez beaucoup d'usines dans votre modèle de domaine, vous ne faites que gaspiller des lignes. de code.

Donc, une fois que vous avez résolu tous ces problèmes, il ne reste plus qu’une validation. C'est le seul qui soit un peu délicat.

La validation fait partie de votre modèle de domaine, mais elle fait également partie de tous les autres composants de l'application. Votre interface utilisateur et votre base de données auront leurs propres règles de validation, similaires mais différentes, basées sur un modèle conceptuel similaire mais différent. Il n'est pas vraiment spécifié si les objets doivent ou non avoir une Validateméthode, mais même s'ils le font, ils la délèguent généralement à une classe de validateur (pas d'interface - la validation n'est pas abstraite dans le modèle de domaine, elle est fondamentale).

Gardez à l'esprit que le validateur fait encore techniquement partie du modèle; il n'a pas besoin d'être attaché à une racine agrégée car il ne contient aucune donnée ni aucun état. Les modèles de domaine sont des éléments conceptuels, traduisant généralement physiquement en un assemblage ou une collection d'assemblages. Ne vous inquiétez pas du problème "anémique" si votre code de délégation réside à proximité immédiate du modèle objet; ça compte toujours.

Ce que tout cela vient vraiment à dire que si vous allez faire DDD, vous devez comprendre ce que le domaine est . Si vous parlez encore de choses comme la persistance et l'autorisation, vous êtes sur la mauvaise voie. Le domaine représente l'état de fonctionnement d'un système - les objets et attributs physiques et conceptuels. Tout ce qui ne concerne pas directement les objets et les relations elles-mêmes n'appartient pas au modèle de domaine, point à la ligne.

En règle générale, pour déterminer si quelque chose appartient ou non au modèle de domaine, posez-vous la question suivante:

"Cette fonctionnalité peut-elle jamais changer pour des raisons purement techniques?" En d'autres termes, pas en raison d'un changement observable dans le monde réel des affaires ou du domaine?

Si la réponse est "oui", alors il n'appartient pas au modèle de domaine. Cela ne fait pas partie du domaine.

Il y a de fortes chances que vous changiez un jour vos infrastructures de persistance et d'autorisation. Par conséquent, ils ne font pas partie du domaine, ils font partie de l'application. Ceci s’applique également aux algorithmes, comme le tri et la recherche; vous ne devriez pas aller implémenter une implémentation de code de recherche binaire dans votre modèle de domaine, car votre domaine ne concerne que le concept abstrait de recherche, pas son fonctionnement.

Si, après avoir éliminé tout ce qui n'a pas d'importance, vous trouvez que le modèle de domaine est vraiment anémique , alors cela devrait être une bonne indication que DDD est tout simplement le paradigme faux pour votre projet.

Certains domaines sont vraiment anémiques. Les applications de bookmarking social n'ont pas vraiment de "domaine" à proprement parler; tous vos objets sont fondamentalement juste des données sans fonctionnalité. Par contre, un système de vente et de gestion de la relation client a un domaine assez lourd. lorsque vous chargez une Rateentité, il est raisonnable de penser que vous pouvez réellement utiliser ce taux, par exemple l'appliquer à une quantité d'ordre et lui demander de déterminer les remises sur volume, les codes promotionnels et tout ce qui est amusant.

Objets de domaine qui vient contiennent des données en général ne signifie pas que vous avez un modèle de domaine anémique, mais cela ne veut pas nécessairement dire que vous avez créé une mauvaise conception - il pourrait juste dire que le domaine lui - même est anémique et que vous devriez utiliser un méthodologie différente.


2
De plus, @SonOfPirate, il n’est pas totalement improbable que vous souhaitiez modifier l’ensemble de votre modèle de sécurité; la sécurité basée sur les rôles est souvent obsolète au profit de la sécurité basée sur les revendications ou les droits, ou peut-être même souhaitez-vous une sécurité au niveau du champ. Imaginez-vous essayer de retravailler votre modèle de domaine entier si cela se produisait.
Aaronaught

1
@SonOfPirate: On dirait presque que vous êtes encore un peu coincé par l'ancien modèle "de niveau métier" dans lequel il existait un "niveau intermédiaire" qui consistait essentiellement en un mince placage sur la couche de données, mettant en œuvre diverses règles commerciales et généralement des règles de sécurité. . Ce n'est pas ce que la couche de domaine est. Tout le reste dépend du domaine. Il représente les objets du monde réel et les relations que le système est censé gérer.
Aaronaught

1
@ LaurentBourgault-Roy: Désolé, je ne te crois pas. Chaque entreprise pourrait en dire autant de chaque application. après tout, changer une base de données est difficile. Cela ne fait pas partie de votre domaine, et la logique métier couplée à la couche de persistance signifie simplement une abstraction médiocre. Un modèle de domaine est axé sur le comportement, ce qui est exactement ce que la persistance n'est pas . Ce n'est pas un sujet sur lequel les gens peuvent inventer leurs propres définitions; c'est assez clairement énoncé dans DDD. Vous n'avez souvent pas besoin d' un modèle de domaine pour les applications CRUD ou de reporting, mais vous ne devez pas non plus prétendre que vous en avez un lorsque vous n'en avez pas.
Aaronaught

1
L'autorisation appartient absolument à la couche de domaine. Qui décide quelles autorisations existent? Les affaires font. Qui décide qui peut faire quoi? Les affaires font. Nous venons de recevoir une demande de fonctionnalité il y a quelques semaines pour modifier l'autorisation nécessaire pour modifier un objet particulier dans notre système. Si un modèle était basé sur un modèle principal, des privilèges plus élevés étaient nécessaires pour modifier (remplacer les valeurs du modèle principal) le modèle par rapport à vos besoins habituels. D'où vient cette logique si ce n'est dans le domaine?
Andy

1
Un autre type d'autorisation pourrait être une limite de compte client. Le personnel du service clientèle peut le relever jusqu’à un certain point, mais des limites plus élevées nécessitent l’approbation de la direction. C'est la logique d'autorisation.
Andy

6

Autorisation. Si l'objet de domaine est responsable de la gestion de ses règles de contrôle d'accès

Non. L'autorisation est une préoccupation en soi. Les commandes qui ne seraient pas valables faute d'autorisations devraient être rejetées avant le domaine, le plus tôt possible - ce qui signifie souvent que nous voudrons même vérifier l'autorisation d'une commande potentielle afin de construire l'interface utilisateur (afin de ne pas même montrer à l'utilisateur l'option de l'édition).

Le partage de stratégies d'autorisation entre les couches (dans l'interface utilisateur et plus loin dans un gestionnaire de service ou de commande) est plus facile lorsque l'autorisation est séparée du modèle de domaine.

L’autorisation contextuelle est un problème difficile à résoudre: une commande peut être autorisée ou non, non seulement en fonction de rôles d’utilisateur mais également de données / règles commerciales.

Validation. La même discussion que ci-dessus concerne la validation.

Je dirais aussi non, pas dans le domaine (principalement). La validation se produit dans différents contextes et les règles de validation diffèrent souvent entre les contextes. Il existe rarement un sens simple et absolu de validité ou d'invalidité lorsque l'on considère les données encapsulées par un agrégat.

De même, comme pour l'autorisation, nous utilisons la logique de validation sur plusieurs couches - dans l'interface utilisateur, dans le gestionnaire de services ou de commandes, etc. Encore une fois, il est plus facile d'utiliser DRY avec validation s'il s'agit d'un composant séparé. D'un point de vue pratique, la validation (en particulier lors de l'utilisation de frameworks) nécessite d'exposer des données qui devraient autrement être encapsulées et il est souvent nécessaire d'attacher des attributs personnalisés aux champs et aux propriétés. Je préfère de loin que ceux-ci soient sur d'autres classes que mes modèles de domaine.

Je préférerais dupliquer certaines propriétés dans quelques classes similaires plutôt que d'essayer d'imposer les exigences relatives à un cadre de validation à mes entités. Cela finit inévitablement par semer le chaos dans les classes d'entités.

Création d'objet. Classe usine par rapport aux méthodes d'usine par rapport à la «réactivation» d'une instance.

J'utilise une couche d'indirection. Dans mes projets plus récents, il s’agit d’une commande + gestionnaire pour créer quelque chose, c’est-à-dire CreateNewAccountCommand. Une alternative pourrait consister à toujours utiliser une fabrique (bien que cela puisse être gênant si le reste d'une opération d'entités est exposé par une classe de service distincte de la classe de fabrique).

En général, cependant, j'essaie d'être plus flexible avec les choix de conception pour la création d'objets. newest facile et familier mais pas toujours suffisant. Je pense qu’il est important de faire preuve de jugement et de permettre à différentes parties d’un système d’utiliser différentes stratégies au besoin.

Persistance. ... pourquoi ne pas avoir une méthode Save sur notre objet domain

C'est rarement une bonne idée. Je pense qu'il y a beaucoup d'expérience partagée pour soutenir cela.

Si je me retrouve avec IAuthorizationService, IValidator, IFactory et IRepository pour ma racine globale, que reste-t-il? Avoir une méthode de publication qui modifie l'état de l'objet de brouillon à publié est suffisant pour considérer la classe comme un objet de domaine non-anémique ???

Peut-être qu'un modèle de domaine n'est pas le bon choix pour cette partie de votre application.


2
«L’autorisation contextuelle est un problème difficile à résoudre: une commande peut être autorisée ou non, non seulement en fonction de rôles d’utilisateur, mais également de données et de règles d’entreprise.» - Et comment abordes-tu cela? Plus souvent qu'autrement, du moins pour moi, nos règles d'autorisation combinent le rôle et l'état actuel.
SonOfPirate

@SonOfPirate: gestionnaires d'événements qui écoutent les événements de domaine et mettent à jour des tables très spécifiques aux besoins des requêtes qui vérifient les autorisations. Une logique qui examine l'état et détermine si un rôle ou une personne est autorisé ou non réside dans le gestionnaire d'événements (les tables sont donc presque toujours un simple oui / non, ce qui permet à l'auth de vérifier une simple recherche). De plus, dès qu'une logique de ce type est utilisée à plus d'un endroit, elle est refactorisée hors du gestionnaire et dans un service partagé.
Quentin-Starin

1
En général, au cours des dernières années, je me suis éloigné de plus en plus pour tenter de tout consolider dans un domaine ou un objet métier. Mon expérience semble être que rendre les choses plus granulaires et moins couplées est une victoire à long terme. Ainsi, d'un point de vue, cette méthode place la logique métier en dehors du domaine (dans une certaine mesure), mais elle prend également en charge les modifications agiles ultérieurement. Il s’agit de trouver un équilibre.
Quentin-Starin

4
Référencement de la réponse elle-même ici: j'ai trouvé le modèle d'état très utile pour les validations qui dépendent à la fois des autorisations et des règles de gestion. Créez un état abstrait qui est injecté dans le modèle de domaine et expose les méthodes qui prennent l'objet de domaine en tant que paramètre et valident les actions spécifiques au domaine. Ainsi, si vos règles d’autorisation changent (comme elles le font presque toujours), vous n’avez jamais à modifier le modèle pour s’y adapter, car les implémentations d’état résident dans votre composant de sécurité.
Aaronaught

1
En ce qui concerne l’autorisation, permettez-moi de donner un exemple concret sur la table pour voir comment vous (les deux) pourriez la gérer. J'ai une opération Publier sur mon objet de domaine qui nécessite que l'utilisateur soit dans le rôle Éditeur et que l'objet se trouve dans un certain état. Je souhaite masquer ou désactiver le "bouton" de publication dans l'interface utilisateur. Comment voulez-vous accomplir cela?
SonOfPirate

4

OK, voilà pour moi. Je préviens cela en disant que:

  • Une optimisation prématurée (y compris la conception) peut souvent poser problème.

  • IANMF (je ne suis pas Martin Fowler);)

  • Un sale petit secret réside dans le fait que, dans les projets de petite taille (même sans doute de taille moyenne), c'est la cohérence de votre approche qui importera.

Autorisation

Pour moi, l'authentification et l'autorisation constituent toujours une préoccupation transversale. Dans mon joyeux petit monde Java, cela est délégué à la sécurité Spring ou au framework Apache Shiro.

Validation Pour moi, la validation fait partie de l'objet, car je la vois comme définissant ce qu'est l'objet.

Par exemple, un objet de voiture a 4 roues (OK il y a quelques exceptions étranges, mais ignorons la voiture étrange à 3 roues pour le moment). Une voiture n'est tout simplement valide que si elle en a 4 (dans mon monde), de sorte que la validation fait partie de la définition d'une voiture. Cela ne signifie pas que vous ne pouvez pas avoir de classes de validation auxiliaires.

Dans mon monde Java heureux, j'utilise des cadres de validation Bean et des annotations simples sur la plupart de mes champs Bean. Il est alors facile de valider votre objet, peu importe la couche dans laquelle vous vous trouvez.

Création d'objet

Je considère les cours d'usine avec prudence. Trop souvent j'ai vu la xyxFactoryFactoryclasse;)

J'ai tendance à simplement créer un newobjet selon les besoins, jusqu'à ce que je rencontre un cas où l'injection de dépendance est justifiée (et puisque j'essaie de suivre une approche TDD, cela se produit plus souvent).

Dans mon joyeux monde Java c'est de plus en plus Guice, mais du printemps est toujours le roi ici.

Persistance

Il s’agit donc d’un débat qui tourne en rond et en rond-point et j’ai toujours deux idées à ce sujet.

Certains disent que si vous regardez un objet de manière "pure", la persistance n'est pas une propriété fondamentale, mais simplement une préoccupation extérieure.

D'autres pensent que vos objets de domaine implémentent implicitement une interface "persistante" (ouais, je sais que j'étire ici). Par conséquent, il est bon d’avoir les différentes méthodes save, deleteetc. Ceci est considéré comme une approche pragmatique et de nombreuses technologies ORM (JPA dans mon heureux monde Java) traitent les objets de cette manière.

Pour des raisons de sécurité transversales, je m'assure que les autorisations modifier / supprimer / ajouter / quels que soient ce paramètre sont correctement définies sur le service qui appelle la méthode save / update / delete sur l'objet. Si je suis vraiment paranoïaque, je pourrais même définir les autorisations sur l'objet de domaine lui-même.

HTH!


2

Jimmy Nilsson aborde ce sujet dans son livre sur le DDD. Il a commencé avec un modèle anémique, a adopté des modèles non anémiques pour un projet ultérieur et a finalement opté pour des modèles anémiques. Son raisonnement était que les modèles anémiques pourraient être réutilisés dans plusieurs services avec une logique métier différente.

Le compromis est le manque de capacité de découverte. Les méthodes que vous pouvez utiliser pour exploiter vos modèles anémiques sont réparties dans un ensemble de services situés ailleurs.


Cela ressemble à une exigence spécifique - la réutilisation des données (structure de données)) - conduit à cette partie commune réduite à de simples DTO.
Victor Sergienko

Les modèles anémiques permettent-ils une meilleure réutilisation? Cela ressemble plus à un DTO, et personnellement, je me fous de la réutilisation des définitions de propriété. Je préfère de loin réutiliser les comportements.
Andy

@Andy - Je conviendrais cependant que si vos comportements sont dans les services de domaine et qu'ils opèrent sur des objets anémiques (ok les DTO si vous le souhaitez), cela n'augmente-t-il pas la réutilisation de ces comportements? Je fais juste l'avocat du diable.
Jpierson

@jpierson J'ai cependant constaté que les comportements sont généralement spécifiques à un cas d'utilisation particulier. S'il y a réutilisation, cela appartiendrait à une autre classe, mais le consommateur n'utiliserait pas ces classes, il utiliserait celles spécifiques au cas d'utilisation. Donc, toute réutilisation est "en coulisse", pour ainsi dire. De plus, essayer de réutiliser des modèles rend généralement les modèles plus difficiles à utiliser pour le consommateur. Vous créez donc des modèles d'affichage / d'édition dans la couche d'interface utilisateur. Souvent, vous finissez par violer DRY pour donner une expérience utilisateur plus riche (par exemple, DataAnnotations des modèles de montage).
Andy

1
Je préfère les modèles de domaine construits pour le cas d'utilisation, réutilisés là où cela a du sens (c'est-à-dire que la réutilisation peut être faite sans modifier le comportement beaucoup ou pas du tout). Ainsi, au lieu d'un modèle de domaine anémique, d'une classe de service et d'un modèle d'édition, vous disposez d'un seul modèle de domaine modifiable intelligent. J'ai trouvé beaucoup plus facile à utiliser et à entretenir.
Andy

2

Cette question a été posée il y a longtemps, mais elle est étiquetée avec Domain Driven Design. Je pense que la question elle-même contient un malentendu fondamental de toute la pratique et que les réponses, y compris la réponse acceptée, perpétuent un malentendu fondamental.

Il n'y a pas de "modèle de domaine" dans une architecture DDD.

Prenons l'autorisation à titre d'exemple. Permettez-moi de vous demander de réfléchir à une question: imaginez deux utilisateurs différents s'authentifier sur votre système. Un utilisateur a la permission de changer une certaine entité, mais l'autre pas. Pourquoi pas?

Je déteste les exemples simples et artificiels parce qu'ils confondent souvent plus qu'ils n'éclairent. Mais supposons que nous ayons deux domaines différents. First est une plate-forme CMS pour une agence de marketing. Cette agence a de nombreux clients qui ont tous un contenu en ligne qui doit être géré par des rédacteurs et des graphistes. Le contenu comprend des articles de blog ainsi que des pages de renvoi pour différents clients.

L'autre domaine est la gestion des stocks pour une entreprise de chaussures. Le système gère les stocks à partir du moment où ils arrivent du fabricant en France, dans les centres de distribution situés aux États-Unis continentaux, dans les magasins de détail sur les marchés locaux et enfin chez le client qui achète les chaussures au détail.

Si vous pensez que les règles d'autorisation sont les mêmes pour les deux sociétés, alors, ce serait un bon candidat pour un service en dehors du domaine. Mais je doute que les règles d'autorisation soient les mêmes. Même les concepts derrière les utilisateurs seraient différents. Le langage serait certainement différent. L'agence de marketing a probablement des rôles de post-auteur et de propriétaire d'actifs, tandis que la société de chaussures a probablement des rôles de commis aux expéditions, de gestionnaire d'entrepôt ou de magasin.

Ces concepts ont probablement toutes sortes de règles de permission associées qui doivent être modélisées dans le domaine. Mais cela ne signifie pas qu'ils font tous partie du même modèle, même au sein de la même application. Parce que rappelez-vous qu'il existe différents contextes délimités.

Donc, on pourrait peut-être considérer qu'un modèle de domaine non anémique dans le contexte de l'autorisation diffère du contexte d'acheminement des expéditions vers des magasins ayant un faible inventaire ou d'acheminer les visiteurs du site vers la page de destination appropriée en fonction de l'annonce sur laquelle ils ont cliqué.

Si vous vous retrouvez avec des modèles de domaine anémique, vous devrez peut-être simplement consacrer plus de temps à la cartographie de contexte avant de commencer à écrire du code.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.