Què és el Domain-Driven Design (DDD)?

La complexitat és un enemic amb què el disseny de software modern sovint ha de conviure, encara que no sempre sigui visible. Quan dissenyem sistemes per a sectors complexos com la banca, la logística o la salut, no n’hi ha prou que la tecnologia funcioni; també ha de parlar el mateix llenguatge que el negoci. Això és precisament el que planteja el Domain-Driven Design (DDD). Eric Evans el va formular l’any 2003 i va defensar que el model de domini havia d’estar al centre del procés de desenvolupament. Com a especialistes en aquest àmbit, sabem que el DDD no és un conjunt rígid de normes, sinó una manera de connectar els objectius estratègics d’una organització amb la seva implementació tècnica, convertint el software d’una simple eina en un autèntic avantatge competitiu.

Disseny estratègic: entendre el negoci

Per entendre el DDD, cal començar per la seva visió estratègica, que ens ajuda a dividir un problema gran en parts més petites i manejables. El Disseny Estratègic és el primer pas. Ens permet identificar on es troba el valor real del negoci. En lloc d’intentar construir un únic model monolític per a tota l’empresa —una aproximació que gairebé sempre acaba fallant—, el DDD ens ajuda a identificar subdominis. El Core Domain és el centre estratègic del negoci; és on es concentra la innovació i on es genera l’avantatge competitiu. És aquí on convé destinar els millors professionals i recursos. No tots els subdominis tenen la mateixa importància. Els Supporting Subdomains, per exemple, aporten funcionalitats necessàries però no diferencials, mentre que els Generic Subdomains representen problemes habituals del negoci que sovint es poden resoldre amb solucions comercials ja existents.

Integració i Bounded Contexts

Aquesta descomposició del problema ens porta a una de les idees més importants del DDD: el Bounded Context. En un sistema gran, diferents equips poden fer servir la mateixa terminologia i els mateixos conceptes amb significats diferents. Per exemple, el departament comercial i el departament de logística no entenen la paraula “comanda” de la mateixa manera. Un bounded context defineix un límit semàntic dins del qual un model és vàlid i consistent. Això aporta claredat i permet que equips diferents evolucionin de manera autònoma. El Context Map és l’eina que fem servir per assegurar que aquests contextos poden col·laborar sense generar conflictes. Mostra com es relacionen mitjançant patrons d’integració com Shared Kernel, Customer-Supplier o la rellevant Anti-Corruption Layer, que protegeix el nostre model de la contaminació provinent de sistemes antics o externs.

El llenguatge ubic

El Ubiquitous Language és l’element que dona coherència a tot el conjunt. No és simplement una llista de termes, sinó un vocabulari compartit, clar i rigorós, construït conjuntament per experts de domini i desenvolupadors. El codi ha de reflectir directament aquest llenguatge comú: noms de classes, mètodes i variables han d’utilitzar els mateixos termes que s’empren en les converses de negoci. Aquest enfocament elimina el costós “impost de traducció” que apareix quan cal passar constantment del món tècnic al món de negoci. Això garanteix que el model representi fidelment les regles de negoci i les necessitats reals.

Disseny tàctic: portar el model a la pràctica

El Disseny Tàctic entra en joc quan passem de la visió estratègica a la implementació concreta. És aquí on identifiquem les peces que fan funcionar el model. Les Entities i els Value Objects són dos dels elements més importants. Una Entity es defineix per la seva identitat única, que es manté al llarg del temps encara que canviïn els seus atributs. Un compte bancari o un client en són bons exemples, perquè ens interessa seguir-ne l’evolució. En canvi, un Value Object no té identitat pròpia i es defineix exclusivament pels seus atributs. A més, és immutable. Si hem de modificar el valor d’una adreça o d’una quantitat de diners, creem un nou objecte en lloc de modificar l’existent. L’ús intensiu de value objects simplifica molt el disseny, ja que elimina efectes secundaris inesperats i facilita el raonament sobre el funcionament del sistema.

Domain Services i Domain Events

Hi ha casos en què certes operacions de negoci no encaixen de manera natural dins d’una entitat o d’un value object concret. En aquestes situacions fem servir Domain Services. Es tracta d’operacions sense estat que encapsulen lògica que afecta diversos objectes del domini. Això permet mantenir les entitats netes i evita que la lògica de negoci acabi dispersa a les capes d’aplicació o d’infraestructura. D’altra banda, un Domain Event serveix per registrar un fet rellevant que ha passat dins del negoci. Aquests esdeveniments són immutables i permeten que diferents parts del sistema es comuniquin sense dependències síncrones. Això fa el sistema més escalable i facilita la consistència eventual entre contextos.

Aggregates i consistència

L’Aggregate és, sens dubte, un dels patrons tàctics més complexos però també més importants. Un aggregate és un conjunt d’objectes (entities i value objects) que es tracten com una única unitat quan es produeixen canvis en les dades, definint així els límits de la consistència transaccional. L’Aggregate Root és l’únic punt d’accés des de l’exterior per modificar aquest conjunt. Aquesta arrel actua com un guardià que assegura que es compleixen tots els invariants —és a dir, les regles de negoci que sempre han de mantenir-se— abans de completar una transacció. Nosaltres recomanem dissenyar aggregates petits per millorar el rendiment i fer servir únicament la identitat (ID) d’altres aggregates, evitant així un acoblament excessiu entre models, seguint les recomanacions de Vaughn Vernon.

Factories i Repositories

El DDD ofereix Factories i Repositories per gestionar el cicle de vida d’aquests objectes complexos. Les Factories s’encarreguen de crear aggregates o entitats amb estructures complexes, assegurant que neixin en un estat vàlid i consistent. Un cop creats, necessitem un mecanisme per emmagatzemar-los i recuperar-los, i aquí és on entren en joc els Repositories. Un repository funciona, conceptualment, com una col·lecció en memòria que amaga completament els detalls d’infraestructura, com ara consultes SQL o bases de dades NoSQL. Això manté el domini net i lliure de preocupacions tècniques.

Arquitectura i separació de responsabilitats

Aquesta separació de responsabilitats és fonamental i es fa possible gràcies a l’arquitectura del sistema. Tant si escollim una Layered Architecture clàssica, que separa Interfície d’Usuari, Aplicació, Domini i Infraestructura, com una Hexagonal Architecture basada en Ports and Adapters, l’objectiu és el mateix: preservar la independència del model de domini. En una arquitectura hexagonal, el domini ocupa el centre i es connecta amb l’exterior mitjançant ports que no depenen de cap tecnologia concreta. Aquests ports són implementats per adapters especialitzats, com una base de dades SQL, una API REST o una interfície web. Aquesta arquitectura garanteix que la lògica de negoci sigui la part més estable i més fàcil de provar del sistema, ja que no depèn de tecnologies que canvien constantment.

Evolució i millora dels models

Finalment, és important recordar que el DDD no és una pràctica que s’aplica només a l’inici d’un projecte. El Refactoring toward Deeper Insight és un procés continu. A mesura que l’equip col·labora més sovint amb els experts de domini, adquireix una comprensió més profunda del negoci. Sovint descobrim que conceptes que semblaven clars necessiten ser redefinits. Els breakthroughs, o moments de descoberta, acostumen a simplificar el model i a fer el disseny més flexible i potent. En definitiva, el Domain-Driven Design és una invitació a desenvolupar software que reflecteixi realment el negoci, utilitzant patrons estratègics i tàctics per reduir la complexitat i assegurar que cada línia de codi contribueixi a l’èxit i a la solidesa de l’organització a llarg termini.

Reflexions finals

El Domain-Driven Design (DDD) és una excel·lent manera d’afrontar la complexitat, perquè garanteix que el software respongui a les necessitats més importants del negoci. Els equips poden construir sistemes alhora flexibles i útils centrant-se en límits estratègics, models explícits i un llenguatge compartit. Els seus patrons tàctics asseguren la consistència i la mantenibilitat, mentre que els seus principis arquitectònics protegeixen el domini davant dels canvis externs. Sobretot, el DDD promou l’aprenentatge continu i la col·laboració, fent possible que els models evolucionin al mateix ritme que ho fa el negoci. Quan s’aplica correctament, converteix el desenvolupament de software en una capacitat estratègica que impulsa la innovació, la claredat i l’èxit a llarg termini.