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

Question

Actualmente al hacer una revisión de código de cosas tomadas de otro equipo y tener una duda sobre la aplicación de SRP y su relación con el modelo de dominio anémico o rico (según lo definido por Martin Fowler). El concepto de modelo de dominio rico es tener un objeto inteligente que no solo pueda establecer/obtener sus propiedades, sino que también puede realizar una lógica comercial 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 en sus proporciones. El siguiente requisito es tener la posibilidad de almacenar estos datos de objeto en algún objeto de almacenamiento que no esté bajo mi control, así:

class MyObject {
    // get set
    // parse sth

}

Método de almacenamiento de almacenamiento

   storage.store(key, object);

¿No viola SRP si MyObject tiene un método de almacén como este?

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

Desde el POV de este objeto, es un buen pensamiento poder almacenar su estado. Otra forma podría ser introducir un tipo de servicio aquí y hacer esto así:

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

¿Puedes señalarme algún enlace que pueda leer sobre este problema? He encontrado un hilo, así que aquí, pero no responde a mi pregunta por completo.

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

Answer 1

Un modelo de dominio rico (RDM) significa que el lógica gobernando el modelo comportamiento pertenece dentro del modelo, en lugar de tratar el modelo como datos con getters/setters. Esto hace no Significa que todo, incluida la persistencia, la 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í.

Violación de 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 ver que tienen demasiadas responsabilidades" es una interpretación simplista de DDD. Siempre depende de cuán buenos son tus modelos. Puede crear modelos malos utilizando DDD (por ejemplo, crear objetos con demasiadas responsabilidades o crear modelos anémicos). DDD y SRP son dos buenas prácticas que también siguen, tanto como la refactorización, TDD y muchos más, pero debe complementar su uso con su experiencia y juicio (o de otra persona). Todo tiene sus pros y contras, no seas dogmático sobre la aplicación de ninguna práctica.

Answer 3

@Garrett Hall

Estoy en desacuerdo con su declaración "RDM y SRP van de la mano, no entran en conflicto entre sí". En mi experiencia, cuando SRP se exagera demasiado, conduce a un modelo de dominio anémico. "No, no podemos hacer o incluso ayudar a apoyar ninguna persistencia, no, no podemos hacer 21 cFr11, no, ni siquiera podemos saber qué es una GUI ..." Y tu clase termina haciendo nada Y solo tengo un modelo de dominio anémico.

Y si RDM se enfatiza demasiado (esa es la dirección/error en la que tiendo a caer), entonces SRP cae por completo en el camino y eventualmente nota que su clase tiene 100 métodos y claramente está haciendo demasiado.

Debe encontrar un equilibrio, el medio feliz donde están ocurriendo RDM y SRP. Y descubrir que el equilibrio es difícil y, a menudo, implica más intestinos y políticas dentro de su equipo que con conocimiento técnico o reglas.

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

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