Disseny basat en dominis
El disseny basat en dominis (DDD) és un enfocament important del disseny de programari,[1] centrat en modelar programari per adaptar-lo a un domini segons les aportacions dels experts d'aquest domini.[2] El DDD s'oposa a la idea de tenir un únic model unificat; en canvi, divideix un sistema gran en contextos delimitats, cadascun dels quals té el seu propi model.[3][4]
En el disseny basat en dominis, l'estructura i el llenguatge del codi de programari (noms de classe, mètodes de classe, variables de classe) han de coincidir amb el domini de l'empresa. Per exemple: si el programari processa sol·licituds de préstec, pot tenir classes com ara "sol·licitud de préstec", "clients" i mètodes com ara "acceptar oferta" i "retirar".
El disseny basat en dominis es basa en els següents objectius:
- centrant el projecte en el domini central i la capa lògica del domini;
- basant dissenys complexos en un model del domini;
- iniciar una col·laboració creativa entre experts tècnics i del domini per refinar iterativament un model conceptual que abordi problemes particulars del domini.
Els crítics del disseny basat en dominis argumenten que els desenvolupadors normalment han d'implementar una gran quantitat d'aïllament i encapsulació per mantenir el model com una construcció pura i útil. Tot i que el disseny basat en dominis ofereix avantatges com ara la mantenibilitat, Microsoft només el recomana per a dominis complexos on el model ofereix avantatges clars en la formulació d'una comprensió comuna del domini.
El terme va ser encunyat per Eric Evans al seu llibre del mateix nom publicat el 2003.[5]
Visió general
[modifica]El disseny basat en dominis articula diversos conceptes i pràctiques d'alt nivell.[6]
De primordial importància és el domini del programari, l'àrea temàtica a la qual l'usuari aplica un programa. Els desenvolupadors de programari construeixen un model de domini : un sistema d'abstraccions que descriu aspectes seleccionats d'un domini i que es pot utilitzar per resoldre problemes relacionats amb aquest domini.
Aquests aspectes del disseny basat en dominis tenen com a objectiu fomentar un llenguatge comú compartit pels experts en dominis, els usuaris i els desenvolupadors: el llenguatge ubic. El llenguatge ubic s'utilitza en el model de domini i per descriure els requisits del sistema.
El llenguatge ubic és un dels pilars del DDD juntament amb el disseny estratègic i el disseny tàctic.
En el disseny basat en dominis, la capa de domini és una de les capes comunes en una arquitectura multicapa orientada a objectes.
Tipus de models
[modifica]El disseny basat en dominis reconeix diversos tipus de models. Per exemple, una entitat és un objecte definit no pels seus atributs, sinó per la seva identitat. Com a exemple, la majoria de les companyies aèries assignen un número únic als seients de cada vol: aquesta és la identitat del seient. En canvi, un objecte de valor és un objecte immutable que conté atributs però no té cap identitat conceptual. Quan la gent intercanvia targetes de visita, per exemple, només es preocupa per la informació de la targeta (els seus atributs) en lloc d'intentar distingir entre cada targeta única.
Els models també poden definir esdeveniments (alguna cosa que va passar en el passat). Un esdeveniment de domini és un esdeveniment que interessa als experts del domini. Els models es poden unir mitjançant una entitat arrel per convertir-se en un agregat. Els objectes fora de l'agregat poden contenir referències a l'arrel però no a cap altre objecte de l'agregat. L'arrel de l'agregat comprova la consistència dels canvis a l'agregat. Els conductors no han de controlar individualment cada roda d'un cotxe, per exemple: simplement condueixen el cotxe. En aquest context, un cotxe és un agregat de diversos altres objectes (el motor, els frens, els fars, etc.).
Treballar amb models
[modifica]En el disseny basat en dominis, la creació d'un objecte sovint se separa de l'objecte en si.
Un repositori, per exemple, és un objecte amb mètodes per recuperar objectes de domini d'un magatzem de dades (per exemple, una base de dades). De la mateixa manera, una fàbrica és un objecte amb mètodes per crear directament objectes de domini.
Quan part de la funcionalitat d'un programa no pertany conceptualment a cap objecte, normalment s'expressa com a servei.
Tipus d'esdeveniments
[modifica]Hi ha diferents tipus d'esdeveniments en DDD, i les opinions sobre la seva classificació poden variar. Segons Yan Cui, hi ha dues categories principals d'esdeveniments:[7]
Esdeveniments de domini
[modifica]Els esdeveniments de domini signifiquen ocurrències importants dins d'un domini empresarial específic. Aquests esdeveniments estan restringits a un context delimitat i són vitals per preservar la lògica empresarial. Normalment, els esdeveniments de domini tenen càrregues útils més lleugeres, que contenen només la informació necessària per al processament. Això es deu al fet que els detectors d'esdeveniments generalment es troben dins del mateix servei, on els seus requisits s'entenen més clarament.[8]
Esdeveniments d'integració
[modifica]D'altra banda, els esdeveniments d'integració serveixen per comunicar canvis entre diferents contextos delimitats. Són crucials per garantir la coherència de les dades a tot el sistema. Els esdeveniments d'integració tendeixen a tenir càrregues útils més complexes amb atributs addicionals, ja que les necessitats dels possibles receptors poden diferir significativament. Això sovint condueix a un enfocament més complet de la comunicació, la qual cosa resulta en una sobrecomunicació per garantir que tota la informació rellevant es comparteixi de manera efectiva.[9]
Patrons de mapatge de context
[modifica]El mapatge de context identifica i defineix els límits de diferents dominis o subdominis dins d'un sistema més gran. Ajuda a visualitzar com aquests contextos interactuen i es relacionen entre si. A continuació es mostren alguns patrons, segons Eric Evans:[10]
- Associació: "forjar una associació entre els equips encarregats dels dos contextos. Instituir un procés per a la planificació coordinada del desenvolupament i la gestió conjunta de la integració", quan "els equips en dos contextos tindran èxit o fracassaran junts"
- Nucli compartit: "Designa amb un límit explícit algun subconjunt del model de domini que els equips acordin compartir. Mantén aquest nucli petit."
- Desenvolupament de clients/proveïdors: "Establir una relació clara entre clients i proveïdors entre els dos equips", quan "dos equips tenen una relació aigües amunt i aigües avall".
- Conformista: "Elimina la complexitat de la traducció [...] triar la conformitat simplifica enormement la integració", quan no és probable que es produeixi una interfície personalitzada per a un subsistema posterior.
- Capa anticorrupció: "crea una capa aïllant per proporcionar al teu sistema la funcionalitat del sistema aigües amunt en termes del teu propi model de domini"
- Servei d'amfitrió obert: "un protocol que dona accés al vostre subsistema com a conjunt de serveis", en cas que sigui necessari integrar un subsistema amb molts altres, fent que les traduccions personalitzades entre subsistemes siguin inviables.
- Llenguatge publicat: "un llenguatge compartit ben documentat que pot expressar la informació de domini necessària com a mitjà de comunicació comú", p. ex., estàndards d'intercanvi de dades en diverses indústries
- Separate Ways (Vies Separades): "un context delimitat [sense] cap connexió amb els altres, que permet als desenvolupadors trobar solucions senzilles i especialitzades dins d'aquest abast reduït"
- Gran bola de fang: "un límit al voltant de tot el desastre" quan no hi ha límits reals per trobar en inspeccionar un sistema existent
Relació amb altres idees
[modifica]Tot i que el disseny basat en dominis no està inherentment lligat als enfocaments orientats a objectes, a la pràctica explota els avantatges d'aquestes tècniques. Aquests inclouen entitats/arrels agregades com a receptores d'ordres/invocacions de mètodes, l'encapsulació de l'estat dins de les arrels agregades més importants i, en un nivell arquitectònic superior, contextos delimitats.
Com a resultat, el disseny basat en dominis sovint s'associa amb objectes Java simples i objectes CLR simples, que són detalls d'implementació tècnica específics de Java i.NET Framework, respectivament. Aquests termes reflecteixen una visió creixent que els objectes de domini s'han de definir únicament pel comportament empresarial del domini, en lloc de per un marc tecnològic més específic.
Mapeig de contextos delimitats a microservices
[modifica]Un context limitat, un concepte fonamental en el disseny basat en dominis (DDD), defineix una àrea específica dins de la qual un model de domini és coherent i vàlid, garantint la claredat i la separació de les preocupacions.[11] En l'arquitectura de microserveis, un context limitat sovint es correspon amb un microservei, però aquesta relació pot variar segons l'enfocament de disseny. Una relació d'un a un, on cada context limitat s'implementa com un únic microservei, sol ser ideal, ja que manté límits clars, redueix l'acoblament i permet el desplegament i l'escalat independents. Tanmateix, altres assignacions també poden ser apropiades: una relació d'un a molts pot sorgir quan un context limitat es divideix en múltiples microserveis per abordar una escalabilitat variable o altres necessitats operatives, mentre que una relació de molts a un pot consolidar múltiples contextos limitats en un únic microservei per simplicitat o per minimitzar la sobrecàrrega operativa. L'elecció de la relació ha d'equilibrar els principis del DDD amb els objectius empresarials, les restriccions tècniques i els requisits operatius del sistema.[12]
Eines destacades
[modifica]Tot i que el disseny basat en dominis no depèn de cap eina o marc de treball en particular, alguns exemples destacables inclouen:
- Actifsource, un complement per a Eclipse que permet el desenvolupament de programari combinant DDD amb enginyeria basada en models i generació de codi.
- Context Mapper, un llenguatge i eines específiques de domini per a DDD estratègic i tàctic.
- CubicWeb, un marc de treball web semàntic de codi obert completament basat en un model de dades. Les directives d'alt nivell permeten refinar el model de dades iterativament, versió rere versió. Definir el model de dades és suficient per obtenir una aplicació web funcional. Cal treballar més per definir com es mostren les dades quan les vistes predeterminades no són suficients.
- OpenMDX, un marc de treball MDA de codi obert basat en Java que admet Java SE, Java EE i.NET. OpenMDX es diferencia dels marcs de treball MDA típics en què "utilitza models per controlar directament el comportament en temps d'execució dels sistemes operatius".
- Objectes Restful, un estàndard per mapejar una API Restful a un model d'objectes de domini (on els objectes de domini poden representar entitats, models de vista o serveis). Dos marcs de treball de codi obert (un per a Java, un per a.NET) poden crear una API d'objectes Restful a partir d'un model de domini automàticament, utilitzant la reflexió.
Referències
[modifica]- ↑ Millet, Scott. Patterns, Principles, and Practices of Domain-Driven Design (en anglès). Indianapolis: Wrox, 2015. ISBN 978-1-118-71470-6.
- ↑ Vernon, Vaughn. Implementing Domain-Driven Design (en anglès). Upper Sadle River, NJ: Addison-Wesley, 2013, p. 3. ISBN 978-0-321-83457-7.
- ↑ Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software (en anglès). Boston: Addison-Wesley, August 22, 2003. ISBN 978-032-112521-7.
- ↑ martinekuan. «Using tactical DDD to design microservices - Azure Architecture Center» (en anglès americà). learn.microsoft.com. [Consulta: 7 setembre 2024].
- ↑ Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software (en anglès). Boston: Addison-Wesley, August 22, 2003. ISBN 978-032-112521-7.
- ↑ Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software (en anglès). Boston: Addison-Wesley, August 22, 2003. ISBN 978-032-112521-7.
- ↑ Cui, Yan. Serverless Architectures on AWS (en anglès). Manning. ISBN 978-1617295423.
- ↑ Cui, Yan. Serverless Architectures on AWS (en anglès). Manning. ISBN 978-1617295423.
- ↑ Cui, Yan. Serverless Architectures on AWS (en anglès). Manning. ISBN 978-1617295423.
- ↑ Evans, Eric. Domain-Driven Design Reference: Definitions and Pattern Summaries (en anglès). ISBN 978-1457501197.
- ↑ Fundamentals of Software Architecture: An Engineering Approach (en anglès). O'Reilly Media, 2020. ISBN 978-1492043454.
- ↑ Building Microservices by Sam Newman (en anglès). ISBN 978-1492034025.
