El 2003, Eric Evan va publicar el seu llibre titulat “Tackling Complexity in the Heart of Software”, en el qual llança els primers conceptes de DDD (Domain-Driven Design), augmentant la seva popularitat de manera exponencial des de llavors.
Molts equips, empreses i organitzacions han aplicat aquest model i han adquirit grans èxits en el desenvolupament de programari.
El Domain-Driven Design (DDD) no és una tecnologia ni una metodologia, sinó una pràctica de desenvolupament de programari amb necessitats complexes, que situa el Domini del Negoci com a far del projecte i al seu Model, com a eina de comunicació entre negoci i tecnologia .
Com sabem, la majoria de les aplicacions d’empresa amb una complexitat empresarial i tècnica significativa es defineixen a partir de múltiples nivells. Aquests nivells són un element lògic i no estan relacionats amb la implementació del servei, sinó que serveixen per ajudar els desenvolupadors a administrar la complexitat del codi.
Posem un exemple:
Prenguem d’exemple una entitat es pot carregar des de la base de dades.
És possible que envieu part d’aquesta informació de la base de dades a la interfície d’usuari del client mitjançant una API web REST.
La qüestió aquí és que l’entitat de domini s’ha de situar dins del nivell de model de domini i no es pot propagar a altres àrees a què no pertany, com al nivell de presentació.
A més, les entitats no poden estar enllaçades a vistes de client, perquè pot ser que algunes dades no estiguin validades al nivell de la interfície d’usuari.
Però aquest és el propòsit del ViewModel, un model de dades exclusiu per a les necessitats del nivell de presentació. Però les entitats de domini no pertanyen directament al model ViewModel. Per això hem de traduir entre ViewModels i entitats de domini, i viceversa.
Vegem a continuació un disseny de capes del microservei DDD:
A la imatge d’anterior, podem veure un disseny a tres capes del microservei DDD Ordering.
Cada capa és un projecte de VS:
És molt important per al seu funcionament correcte que cada nivell es comuniqui només amb altres nivells determinats. A més, aquest enfocament de desenvolupament pot ser més fàcil aplicar si els nivells s’implementen com a biblioteques de classe diferents, ja que ens permet identificar clarament quines dependències s’estableixen entre les diferents biblioteques.
El nivell de model de domini és el nivell responsable de representar conceptes del negoci, informació sobre la situació del negoci i les regles de negocis.
L’estat que reflecteix la situació empresarial està controlat i es fa servir aquí, però els detalls tècnics del seu emmagatzematge es deleguen a la infraestructura.
Podem dir que aquest nivell és el nucli del programari empresarial.
El nivell d’aplicació defineix els treballs i les tasques que se suposa que ha de fer el programari i dirigeix els objectes de domini expressiu perquè resolguin problemes.
Les tasques que són responsabilitat d’aquest nivell són significatives per a l’empresa o necessàries per a la interacció amb els nivells d’aplicació d’altres sistemes, per això aquest nivell s’ha de mantenir estret.
Aquest nivell no conté regles de negocis ni coneixements, sinó que només coordina tasques i delega feina a col·laboracions d’objectes de domini al nivell següent.
A més, no compta amb cap estat que reflecteixi la situació empresarial, però pot tenir un estat que reflecteixi el progrés duna tasca per a l’usuari o el programa.
El nivell d’infraestructura és la manera com les dades que inicialment es conserven a les entitats de domini, a la memòria, es guarden en bases de dades o en un altre magatzem permanent.
Un exemple seria utilitzar codi d’Entity Framework Core per implementar les classes del patró de repositori que utilitzen DBContext per conservar les dades en una base de dades relacional.
A continuació, podeu observar les dependències, idònies, que hauria de tenir cada capa en un servei de Domain-Driven Design:
Com podem veure a l’esquema anterior, la capa d’aplicació depèn del domini i la infraestructura, i la infraestructura depèn del domini, però el domini no depèn de capa.
Com tots els models, el Domain-Driven Design compta amb beneficis a favor seu i alguns desavantatges en contra, però com sempre us diem, depenent de les vostres necessitats o les del vostre client, cal analitzar cada cas i estudiar quin model és més convenient.
Vegem quins són els avantatges i els desavantatges d’aquest model: