Domain-Driven Design, Què és i com aplicar-ho a la meva organització?
Què és el Domain-Driven Design (DDD)?
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 s’aplica el Domain-Driven Design (DDD)?
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.
ViewModel
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.
Quins nivells té Domain-Driven Design?
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:
- La capa d’aplicación és Ordering.API
- El nivell de dominio és Ordering.Domain
- El nivell d’infraestructura és Ordering.Infrastructure
É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.
Els 3 nivells de Domain-Driven Design (DDD)
Model de domini
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.
Aplicació
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.
Infraestructura
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.
Avantatges i desavantatges del model?
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:
Avantatges de Domain-Driven Design
- Codi ben organitzat, permetent el testing de les diferents parts del domini de manera aïllades
- Lògica de negoci resideix en un sol lloc i dividida per contextos
- Mantenibilitat a llarg termini
- Comunicació efectiva entre experts del domini i experts tècnics a través d’Ubiquitous Language (Llenguatge Ubic)
Desavantatges de Domain-Driven Design
- Experiència al domini: Domain-Driven Design requereix una àmplia experiència en el domini. Això vol dir que l’equip hauria de tenir almenys un expert en domini que ajudi a definir tots els processos, procediments i terminologia d’aquest domini
- Costos de desenvolupament: l’equip ha d’implementar una gran quantitat d’aïllament i encapsulació dins del model de domini. Això sovint dóna com a resultat un desenvolupament i una durada més perllongats, que poden tenir un cost relativament alt. Per això podem dir que no és un model adequat per a projectes a curt termini o projectes sense una gran complexitat de domini.