Je travaille avec un système hérité qui a un modèle anémique em>. Le domaine est l'entité suivante: Pour chacun de ceux-ci, il existe un référentiel séparé. Il existe également un certain nombre de services qui accèdent à ces référentiels et contiennent fondamentalement toute la logique. P> Je dois mettre en œuvre une méthode qui détermine si un Initialement, j'ai implémenté cela dans une classe de service. P> voiture code>, cartype Code>, carcommonent code>, carcommonenttype code>. p> carcommonenttype code> peut être interrompu par le fournisseur. La logique est la suivante: Un composant ne peut être interrompé que s'il n'y a pas de voitures existantes avec ce composant aujourd'hui. P> public boolean canBeDiscontinued() {
List<Car> cars = carRepository.getCarsWithComponent(this);
return cars.isEmpty();
}
4 Réponses :
Cela ressemble à un bon candidat pour le modèle de spécification
Dans quelle couche ferais-je la mise en œuvre de la spécification? Infrastructure?
La spécification fait partie intégrante de la couche de domaine, car les «concepts de domaine» sont mis en œuvre dans la spécification.
La réponse de Frederik Gheysels est bonne, bien que peut-être un peu courte. Pour élaborer: Dans votre cas, vous pouvez commencer par définition d'une interface pour votre spécification (excuse ma syntaxe C #): Vous pouvez ensuite créer une implémenetation d'icarsPécissement utilisant votre référentiel qui utilise votre référentiel. Quelque chose comme ceci: Vous pouvez arrêter ici, mais la chose que je n'aime pas particulièrement sur le modèle de spécification, c'est que ce n'est pas très découvertable. Une solution possible consisterait à injecter la spécification dans le CarComponentType lui-même: Alternativement, si vous n'aimez pas transporter la spécification dans chaque cas de la classe, vous pourrait utiliser une injection de méthode au lieu de l'injection de constructeur: une telle méthode n'ajoute aucune valeur en termes de mise en œuvre, mais est plus découvertable.
Merci de clarifier. Si j'avais plus de spécifications pouvant être combinées, cela semble approprié. Dans mon cas, je ne suis pas sûr. Au lieu d'injecter un référentiel dans chaque entité, j'injecte une spécification qui utilise un référentiel. Est-ce vraiment tellement mieux?
Eh bien, il découle votre classe du référentiel et il est probablement plus facile à tester un appareil en passant dans des implémentations de spécification qui font ce que vous voulez pour un test.
Oui: Quels chriskes vient de dire :) Sérieusement, cela rend la spécification qu'une autre stratégie, qui peut dépendre ou non de dépendre d'un référentiel. Néanmoins, j'ai inclus l'alternative d'injection de méthode au cas où vous n'avez pas vraiment aimé une dépendance universelle sur la spécification.
Je suis réticent. Je vois l'avantage de découpler, mais cela semble presque comme la "couche inutile de la couche inutile" si j'utilise tout cela sur la place.
@waxwing: Ne prenez pas ma réponse comme une tentative de vous persuader de faire une chose ou l'autre. Je ne l'entendis que comme une élaboration sur les directions possibles que vous pourrait prendre. Personnellement, j'aime garder mes entités de domaine comme Pocos / Pojos, alors injecter la spécification dans le CarComponentType n'est pas ma solution préférée. Comme alternative, vous pourriez simplement avoir une propriété booléenne sur la classe et avoir une usine (qui connaît la spécification) la configurante correctement.
Je ne pense pas que ce soit un euphémisme de dire que je déteste les modèles de domaine anémique autant que le prochain homme.
Toutefois, étant donné que le système que vous travaillez a déjà établi le modèle de modèle anémique de domaine / service (anti), je pense que l'introduction de modèles supplémentaires pourrait être de la dissuasion du système lorsqu'il est fait dans des cas isolés, car je pense que vous avez ici. Une telle décision devrait être faite par l'équipe et devrait avoir des avantages clairs.
En outre, IMHO, je pense que vos extraits de code d'origine sont plus simples que les solutions proposées dans d'autres réponses (aucune infraction de marque et Frederik, juste une observation :-) et que la solution la plus compliquée n'apporte pas vraiment aucun avantage - je Moyenne, la fonctionnalité est la même dans les deux cas, mais l'utilise ultérieurement plus pièces mobiles .
en termes de comment procéder, avec un seul exemple, il est difficile de dire. L'introduction d'un orj (que vous avez mentionné n'est pas actuellement utilisé) pourrait être une solution pour réduire le code dans vos classes de service et aurait des avantages clairs, donc je serais tenté de commencer là, puis une fois que c'est en place examen la situation.
Merci. J'avais presque résigné cette réponse moi-même, mais je me demandais des objectifs académiques. Je pense que devrait être une solution plus intelligente que je ne vois pas.
Je ne pense pas que la "puisse être discontinue" appartient à l'une de ces classes. Qui est responsable de déterminer si une partie peut être discontinue? Pas la voiture ou le composant de la voiture. Je pense que vous étiez sur la bonne voie avec votre méthode initiale mise en œuvre dans un service. Peut-être avez-vous besoin d'un carinVentetoryManageService qui est responsable de répondre à des questions sur les éléments de l'inventaire de voitures telles que:
carsUsingComponent( CarComponent comp ) canComponentBeDiscontinued( CarComponent comp ) etc
Ceci est un peu subjectif. Il est plus souvent que non pas une affaire limite si l'objet de domaine devrait être «au courant» de la manière dont il est utilisé par les clients. Peut-être que vous avez raison dans ce cas. Mais disons que c'est une fonction différente - quelque chose qui convient incontestablement dans CARCOMPONENTTTYPE mais nécessite des données non contenues dans l'objet lui-même. C'est ce que je suis plus intéressant.
Je pense que la responsabilité a motivé la conception. Une voiture serait-elle la seule responsable de déterminer s'il est toujours en production ou le créateur de la voiture? Une voiture peut certainement savoir qui le produit, mais il n'a pas vraiment aucune raison de tenir la responsabilité de prendre des décisions sur la question de savoir si toutes les voitures de ce type sont, disent, fin de la fin de la vie. Les objets de domaine ne doivent généralement répondre que des questions sur eux-mêmes. Les questions qui s'appliquent à tous un type d'objet de domaine sont généralement la responsabilité d'un service d'objet de domaine. Je ne connais évidemment pas ce logiciel, mais c'est un principe général.