¿Cómo se relaciona el principio de responsabilidad única con el modelo de dominio anémico/rico?

Question

Actualmente estoy haciendo una revisión del código de material tomado de otro equipo y tengo una duda sobre la aplicación de SRP y su relación con el modelo de dominio anémico o rico (como lo define Martin Fowler). El concepto de modelo de dominio enriquecido es tener un objeto inteligente que no solo puede establecer/obtener sus propiedades, sino que también puede realizar una lógica de negocios más complicada. Me pregunto cómo encaja en SRP?

Digamos que tengo mi clase de modelo que tiene algunas propiedades que pueden exponer esos accesorios y proporcionar algunos cálculos simples sobre sus propiedades. A continuación requisito es tener la posibilidad de almacenar estos datos de objeto en un objeto de almacenamiento que no está bajo mi control, así: método

class MyObject { 
    // get set 
    // parse sth 

} 

tienda en el almacenamiento

storage.store(key, object); 

¿No se viola si SRP MiObjeto tiene método tienda como esta

public void store(Storage storage) { 
    storage.store('keyOne', fieldOne); 
    storage.store('keyTwo', fieldTwo); 
} 

de Punto de vista de este objeto es una buena pensar que ser capaz de almacenar su estado. Otra forma podría ser la introducción de una especie de servicio aquí y hacer esto así:

public StorageService { 
    private Storage; 
    // constructor here 
    .... 
    public void store(MyObject myobj); 
} 

¿Me puede indicar cualquier enlace que puede leer acerca de este problema? He encontrado un hilo en SO aquí, pero no responde mi pregunta por completo.

¿Cómo se resuelve en DDD? Los modelos en DDD son, por definición, ricos y se puede considerar que tienen demasiadas responsabilidades.

Answer 1

Un rico modelo de dominio (RDM) significa que la lógica rige el comportamiento del modelo de pertenece dentro del modelo, en contraposición a tratar el modelo como datos con getters/setters. Esto no incluye sino todo lo que incluye persistencia, seguridad, cómo mostrar el modelo en la GUI, etc. debe estar dentro del modelo.

RDM y SRP van de la mano, no entran en conflicto entre sí.

Violar SRP/RDM:

Car { 
    // possibly violates SRP 
    storeInDatabase(); 
    // smells like anemic domain model 
    getEngineState(); 
} 

Siguiendo SRP/RDM:

// usings aspects to remove cross-cutting concerns from the model and follow SRP 
@DatabaseSerializable 
Car { 
    // rich domain model encapsulates engine state and exposes behavior 
    drive();    
} 

Answer 2

"Los modelos en DDD son por definición ricos y se puede considerar que tienen demasiadas responsabilidades" es una interpretación simplista de DDD. Siempre depende de qué tan buenos sean tus modelos. Puede crear modelos incorrectos usando DDD (por ejemplo, crear objetos con demasiadas responsabilidades o crear modelos anémicos). DDD y SRP también son dos buenas prácticas, tanto como refactorización, TDD y muchas más, pero debe complementar su uso con su experiencia y criterio (o el de otra persona). Todo tiene sus pros y sus contras, no seas dogmático al aplicar cualquier práctica.

Answer 3

@Garrett Salón

que algo en desacuerdo con su declaración "RDM y SRP ir mano a mano, no entran en conflicto entre sí."En mi experiencia, cuando se sobre enfatiza la SRP, conduce a un modelo de dominio anémico". No, no podemos hacer o incluso ayudar a respaldar cualquier persistencia, no, no podemos hacer 21-CFR11, no, no podemos incluso saber lo que es una interfaz gráfica de usuario ..." y la clase termina haciendo nada y sólo tienen un modelo de dominio anémico.

y si se insistirá lo suficiente RDM (que es la dirección/error tiendo a caer en) entonces SRP queda completamente en el camino y eventualmente notará que su clase tiene cientos de métodos y claramente está haciendo demasiado.

Necesita encontrar un equilibrio, el medio feliz donde están sucediendo tanto RDM como SRP. Y encontrar ese equilibrio es difícil y, a menudo implica más sentimientos viscerales y la política dentro de su equipo que la experiencia técnica o reglas

"Conócete a ti mismo". Si eres como yo y te inclinas por las clases excesivamente complejas, ten en cuenta. Y cuando ves la clase de otra persona que se ve demasiado compleja, incluso para ti, es una gran bandera roja. Del mismo modo, si sabes que eres bastante duro con SRP, y ves una clase que parece anémica incluso para tus estándares, ese es un gran olor a código.

Ahora, respondiendo algo a la pregunta del OP sobre el almacenamiento, creo que mucho depende de cuán estable, estándar y abstracto sea el almacenamiento. Si Storage fuera una abstracción estándar de XML, CSV o RDB, no tengo absolutamente ningún problema con que los objetos sepan cómo almacenarse.