on essendo presente nella Domain Driven Design un vero e proprio manifesto o dei comandamenti, ho fatto in modo che da un estratto della mia bibbia...se ne potessero tirare fuori alcuni.
Sono generici e saranno completati poi da modalità più specifiche di design, ma devo dire che già espressi in questa forma fanno il loro effetto:
- Partizionare le applicazioni in Layer.
- Il design dei layer deve garantire la loro coesione.
- I Layer dovrebbero dipendere solo da layer sottostanti.
- Usare pattern architetturali per garantire un basso accoppiamento di un layer con un altro.
- Concentrare tutto il codice che riguarda il Domain Model in un layer specifico. Isolare il questo codice di dominio da responsabilità di interfaccia, applicative, o di infrastruttura.
Parola di Eric...rendiamo grazie.
Ovviamente notiamo che alcuni principi sono fondamentalmente di Object Oriented Design pura.
Un forte accento va però messo nell'isolamento del Domain Layer. Il suo isolamento da responsabilità infrastrutturali, o di visualizzazione, gli da la concreta possibilità di rappresentare in modo efficace il modello analitico. Tutto questo guadagnando in semplicità di lettura, di testabilità e manutenibilità.
Il Domain Layer sarà sempre il collante, tra il modello implementativo e il modello analitico.
Una modifica al domain layer, implica cambiamenti implementativi (sul codice) e concordemente al modello analitico stesso (ad esempio nei vostri diagrammi UML se lo avete rappresentato così).