Come singolo Responsabilità principio si riferisce alla ricca modello anemico / dominio?

Question

Al momento a fare qualche revisione del codice di roba preso da un'altra squadra e hanno un dubbio circa l'applicazione SRP e la sua relazione con modello di dominio anemico o ricchi (come definito da Martin Fowler). Rich concetto di modello di dominio è quello di avere oggetto intelligente che può non solo impostare / ottenere le loro proprietà, ma anche in grado di eseguire una logica di business più complicato. Ho wond come si inserisce nella SRP?

Di 'Ho la mia classe del modello che ha alcune proprietà che possono esporre quegli oggetti di scena e di fornire alcuni semplici calcoli sulle sue properies. requisito successivo è quello di avere la possibilità di memorizzare questi dati oggetto in un oggetto di archiviazione che non è sotto il mio controllo, come questo:

class MyObject {
    // get set
    // parse sth

}

metodo Store di stoccaggio

   storage.store(key, object);

non è violare SRP se MyObject ha metodo negozio come questo

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

Da punto di vista di questo oggetto è una buona pensare di essere in grado di memorizzare il suo stato. Altro modo potrebbe essere quello di introdurre una sorta di servizio qui e fare questo genere:

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

Mi può indicare tutti i link che può leggere su questo problema? Ho trovato un thread su SO qui, ma non risponde completamente alla mia domanda.

Come si risolve in DDD? Modelli in DDD sono per definizione ricchi e possono essere visti come avere troppe responsabilità.

Answer 1

Un ricco modello di dominio ( RDM ) significa che la logica di governo del modello comportamento appartiene all'interno del modello, al contrario di trattare il modello come i dati con getter / setter. Questo fa non tutto media compresa la persistenza, la sicurezza, come visualizzare il modello nella GUI, ecc deve essere all'interno del modello.

RDM e SRP vanno di pari passo, non entrano in conflitto con l'altro.

La violazione SRP / RDM:

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

A seguito di 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

"Models in DDD are by definition rich and can be seen as having too many responsibilities" is a simplistic interpretation of DDD. Always it depends in how good are your models. You could create bad models using DDD (for example creating objects with too many responsabilities or creating anemic models). DDD and SRP are two good practices too follow, as much as refactoring, TDD and many more, but you should complement their use with your experience and judgement (or someone else's). Everything has its pros and cons, don't be dogmatic about applying any practice.

Answer 3

@Garrett Hall

I somewhat disagree with your statement "RDM and SRP go hand-in-hand, they do not conflict with each other." In my experience, when SRP is overemphasized, it leads to an anemic domain model. "No, we can't do or even help support any persistance, no, we can't do 21-CFR11, no, we can't even know what a GUI is..." and your class ends up doing nothing and just have an Anemic Domain Model.

And if RDM is overemphasized (that's the direction/error I tend to fall into) then SRP completely falls by the wayside and you eventually notice that your class has 100s of methods and is clearly doing too much.

You need to find a balance, the happy medium where both RDM and SRP are happening. And finding that balance is hard and often involves more gut-feelings and politics within your team than technical savvy or rules.

"Know thyself". If you are like me, and tend towards overly complex classes, be aware. And when you see somebody else's class that looks too complex even to you, that a big red flag. Likewise, if you know that you are pretty hardcore about SRP, and you see a class that looks anemic even by your standards, that's a major code smell.

Now, somewhat answering the OP's question about Storage, I think a lot depends on how stable, standard, and abstract Storage is. If Storage were some standard XML, CSV, or RDB abstraction, I have absolutely no problem with objects knowing how to store themselves.