Actuellement en faisant un examen de code des trucs pris d'une autre équipe et avoir un doute sur l'application de SRP et son rapport avec un modèle de domaine anémique ou riche (tel que défini par Martin Fowler). Le concept de modèle de domaine riche est d'avoir un objet intelligent qui peut non seulement définir / obtenir leurs propriétés, mais peut également effectuer une logique commerciale plus compliquée. Je me demande comment il s'adapte à SRP?
Dites que j'ai ma classe modèle ayant des propriétés pouvant exposer ces accessoires et fournir des calculs simples sur ses homologues. L'exigence suivante consiste à avoir la possibilité de stocker ces données d'objet dans certains objets de stockage qui ne sont pas sous mon contrôle, comme celui-ci: P> Méthode de stockage en stock p> public StorageService {
private Storage;
// constructor here
....
public void store(MyObject myobj);
}
3 Réponses :
"Les modèles de DDD sont par définition riches et peuvent être considérés comme ayant trop de responsabilités" est une interprétation simpliste du DDD. Toujours cela dépend de la qualité de vos modèles. Vous pouvez créer de mauvais modèles à l'aide de DDD (par exemple, créer des objets avec trop de responsabilités ou créer des modèles anémiques). DDD et SRP sont deux bonnes pratiques également suivent, autant que le refactoring, TDD et bien d'autres, mais vous devriez compléter leur utilisation avec votre expérience et votre jugement (ou de quelqu'un d'autre). Tout a ses avantages et ses inconvénients, ne soyez pas dogmatique à l'application d'une pratique.
Un modèle de domaine riche ( RDM ) signifie que la logique logique Gubliez le comportement appartient dans le modèle, par opposition au traitement du modèle comme des données avec getters / setters. Cela fait non signifie tout ce dont la persistance, la sécurité, la manière d'afficher le modèle dans l'interface graphique, etc. doit être dans le modèle. RDM et SRP vont de la main dans la main, ils font pas en conflit les uns avec les autres. violer SRP / RDM: suivant SRP / RDM:
Si vous avez une voiture avec de nombreuses autres méthodes, à l'exception de la juste lecteur (), par exemple Switchon (), Suteloff (), Turn (), Frein (), PlanRoute (), vous avez des RDM, mais vous n'avez pas de SRP . Plus votre classe est riche en comportement, plus elle va à l'encontre de SRP. Ce sont des idées opposées.
RDM signifie que votre modèle doit contenir une logique de domaine. SRP signifie que vos classes devraient être responsables d'une chose - dans le cas du modèle, cela signifie «contenant la logique de domaine», et ne contenant pas de code de sérialisation ou de code qui ouvre une connexion Web, etc.
Je suis au courant des significations. Juanze dit mieux: "Les modèles de DDD sont par définition riches et peuvent être considérés comme ayant trop de responsabilités". En d'autres termes, il n'est pas facile de mettre en œuvre une entité vraiment riche sans cette entité ayant trop de responsabilités (plus de 1). Sauf si bien sûr, nous injectons des services de responsabilités ou des objets à une responsabilité unique, auquel cas elle est limite ADM.
@garrett Hall
J'ai un peu en désaccord avec votre déclaration "RDM et SRP vont à la main, ils ne sont pas en conflit les uns avec les autres." D'après mon expérience, lorsque SRP est surestimée, cela conduit à un modèle de domaine anémique. "Non, nous ne pouvons pas faire ou même aider à soutenir une persistance, non, nous ne pouvons pas faire 21-CCR11, non, nous ne pouvons même pas savoir ce qu'est une interface graphique ..." et votre classe finit par faire rien et il suffit d'avoir un modèle de domaine anémique.
et si RDM est sursultisé (c'est la direction / erreur que j'ai tendance à tomber dans) puis SRP tombe complètement au bord de la route et que vous remarquez finalement que votre classe a 100 méthodes et cela fait clairement trop.
Vous devez trouver un équilibre, le support heureux où RDM et SRP se produisent. Et constater que l'équilibre est difficile et implique souvent plus de sentiments intestinaux et de politiques au sein de votre équipe que de Savvie ou de règles techniques.
"Savoir toi-même". Si vous êtes comme moi et tendez-vous vers des classes trop complexes, soyez conscient. Et quand vous voyez la classe de quelqu'un d'autre qui a l'air trop complexe, même pour vous, qu'un grand drapeau rouge. De même, si vous savez que vous êtes assez hardcore à propos de SRP et que vous voyez une classe qui a l'air anémique même selon vos normes, c'est une odeur de code majeure.
Maintenant, quelque peu de répondre à la question de l'OP sur le stockage, je pense que beaucoup dépend de la stabilité, du stockage standard et abstrait. Si le stockage était une abstraction standard XML, CSV ou RDB, je n'ai absolument aucun problème avec des objets sachant comment se stocker.
SRP dit qu'une classe doit avoir une raison de changer, et cela signifie une source de raison de changer. Ainsi, lorsque différents comportements existent pour un objet, ils doivent être séparés en différentes classes et ces classes (qui sont des services dans DDD) appartiennent au modèle de domaine.
Cela pourrait être une interprétation trop littérale de SRP. Ignorer oncle Bob et aller pour "cohésion".
Comme indiqué dans ma réponse, si le stockage est stable et abstrait (par exemple, une interface standard JSON, XML, RDB) alors, imo, il n'y a absolument aucun problème à la cohésion et à la mettre dans le modèle de domaine.