El disseny impulsat per dominis (DDD) és un enfocament del desenvolupament de programari que se centra a comprendre i modelar el domini del problema en el qual opera un sistema de programari. Subratlla la importància de col·laborar estretament amb experts del domini per desenvolupar una comprensió profunda de les complexitats i complexitats del domini. DDD proporciona un conjunt de principis, patrons i pràctiques per ajudar els desenvolupadors a capturar i expressar de manera eficaç els conceptes de domini en els seus dissenys de programari.

diferència entre un lleó i un tigre

Temes importants per al disseny basat en dominis (DDD)

• Què és el disseny impulsat per dominis (DDD)?
• Importància del coneixement del domini
• Disseny estratègic en disseny impulsat per dominis (DDD)
• Patrons de disseny tàctic en disseny basat en dominis (DDD)
• Beneficis del disseny basat en dominis (DDD)
• Reptes del disseny impulsat per dominis (DDD)
• Casos d'ús del disseny basat en dominis (DDD)
• Exemple real de disseny basat en dominis (DDD)

Què és el disseny impulsat per dominis (DDD)?

Domini

Es refereix a l'àrea temàtica o l'espai del problema per al qual s'està construint el sistema de programari. Inclou els conceptes, regles i processos del món real que el programari pretén modelar o donar suport. Per exemple, en una aplicació bancària, el domini inclou conceptes com ara comptes, transaccions, clients i regulacions relacionades amb les operacions bancàries.

Impulsat

Driven implica que el disseny del sistema de programari està guiat o influenciat per les característiques i requisits del domini. En altres paraules, les decisions de disseny es basen en una comprensió profunda del domini, en lloc de ser impulsades únicament per consideracions tècniques o detalls d'implementació.

Disseny

El disseny fa referència al procés de creació d'un pla o plànol per al sistema de programari. Això inclou decisions sobre com s'estructurarà el sistema, com interactuaran els diferents components i com el sistema complirà el seu funcional i no funcional requisits. En el context del disseny basat en dominis, l'objectiu és dissenyar el programari d'una manera que reflecteixi amb precisió l'estructura i el comportament del domini.

El disseny basat en dominis és un concepte introduït per un programador Eric Evans l'any 2004 en el seu llibre Disseny basat en dominis: abordar la complexitat al cor del programari

Importància del coneixement del domini

Suposem que hem dissenyat programari utilitzant tota la tecnologia i la infraestructura més recents i la nostra arquitectura de disseny de programari és increïble, però quan llancem aquest programari al mercat, en última instància, és l'usuari final qui decideix si el nostre sistema és fantàstic o no. A més, si el sistema no resol les necessitats empresarials, no serveix per a ningú. No importa el bonic que sembli o el bé que sigui l'arquitectura de la seva infraestructura.

D'acord amb Eric Evans Quan estem desenvolupant programari, el nostre enfocament no ha de centrar-se principalment en la tecnologia, sinó principalment en els negocis. Recordeu,

No és feina del client saber què vol, Steve Jobs

Disseny estratègic en disseny impulsat per dominis (DDD)

El disseny estratègic en el disseny impulsat per dominis (DDD) se centra a definir l'arquitectura i l'estructura generals d'un sistema de programari d'una manera que s'alinea amb el domini del problema. Aborda qüestions d'alt nivell, com ara com organitzar els conceptes de domini, com dividir el sistema en parts manejables i com establir límits clars entre diferents components.

Vegem alguns conceptes clau dins de Disseny estratègic en disseny impulsat per dominis (DDD)

1. Contextos acotats

• Un context limitat representa una àrea específica dins del domini global del problema on un model o llenguatge concret s'aplica de manera coherent.
• Diferents parts d'un sistema poden tenir significats diferents per als mateixos termes, i un context limitat defineix límits explícits dins dels quals aquests termes tenen significats específics.
• Això permet als equips desenvolupar models que s'adapten a contextos específics sense introduir confusió o inconsistències.
• Els contextos limitats ajuden a gestionar la complexitat desglossant un domini gran i complex en parts més petites i més manejables.

2. Mapes de context

• El mapa de context és el procés de definir les relacions i interaccions entre diferents contextos acotats.
• Implica identificar àrees de superposició o integració entre contextos i establir canals de comunicació i acords entre ells.
• El mapatge de context ajuda a garantir que les diferents parts del sistema puguin col·laborar de manera eficaç tot mantenint els límits clars entre elles.
• Hi ha diversos patrons i tècniques per al mapeig de context, com ara l'associació, el nucli compartit i el client-proveïdor.

3. Patrons estratègics

• Els patrons estratègics són directrius o principis generals per organitzar l'arquitectura d'un sistema de programari d'una manera que s'alinea amb el domini del problema.
• Aquests patrons ajuden a abordar els reptes comuns en el disseny de sistemes complexos i proporcionen enfocaments provats per estructurar el sistema de manera eficaç.
• Alguns exemples de patrons estratègics inclouen agregats, esdeveniments de domini i capa anticorrupció.
• Aquests patrons proporcionen solucions als problemes recurrents en el disseny basat en dominis i ajuden a garantir que l'arquitectura del sistema reflecteixi amb precisió els conceptes de domini subjacents.

4. Nucli compartit

• El nucli compartit és un patró estratègic que implica identificar àrees de comú entre diferents contextos limitats i establir un subconjunt compartit del model de domini que s'utilitza per diversos contextos.
• Aquest subconjunt compartit, o nucli, ajuda a facilitar la col·laboració i la integració entre contextos alhora que permet que cada context mantingui el seu propi model diferent.
• El nucli compartit s'ha d'utilitzar amb criteri, ja que introdueix dependències entre contextos i pot conduir a l'acoblament si no es gestiona amb cura.

5. Capa anticorrupció (ACL)

• La capa anticorrupció és un altre patró estratègic que ajuda a protegir un sistema de la influència de sistemes externs o heretats que utilitzen models o llenguatges diferents.
• Una ACL actua com a capa de traducció entre el sistema extern i el model de domini principal, transformant les dades i els missatges segons sigui necessari per garantir la compatibilitat.
• Això permet que el model de domini principal es mantingui pur i centrat en el domini del problema, alhora que s'integra amb sistemes externs segons sigui necessari.

6. Llenguatge omnipresent

El llenguatge ubicu fa referència a un vocabulari o llenguatge compartit que s'utilitza de manera coherent i universal entre tots els agents implicats en el desenvolupament d'un sistema de programari. Aquest llenguatge consta de termes, frases i conceptes que representen amb precisió el coneixement i els conceptes del domini.

Alguns dels principis clau del llenguatge ubicu són:

int a cadena java

• Comprensió compartida : L'objectiu principal d'Ubiquitous Language és establir una comprensió compartida del domini del problema entre tots els membres de l'equip de desenvolupament, inclosos els desenvolupadors, els experts del domini, els analistes de negocis i les parts interessades. Mitjançant l'ús d'un llenguatge comú, tots els implicats poden comunicar-se de manera més eficaç i transmetre amb precisió els conceptes i els requisits del domini.
• Coherència i Claredat : Ubiquitous Language promou la coherència i la claredat en la comunicació mitjançant l'ús de terminologia precisa i sense ambigüitats. Cada terme o frase de la llengua ha de tenir un significat clar i consensuat,
• Alineació amb els conceptes empresarials : El llenguatge utilitzat a DDD ha d'estar molt alineat amb la terminologia i els conceptes utilitzats en el domini empresarial. Hauria de reflectir la manera com els experts del domini pensen i parlen sobre el domini del problema, assegurant que el programari representi amb precisió els conceptes i els processos del món real.
• Naturalesa Evolutiva : El llenguatge ubicu no és estàtic, sinó que evoluciona amb el temps a mesura que l'equip adquireix una comprensió més profunda del domini i a mesura que canvien els requisits. S'ha d'adaptar per reflectir nous coneixements, descobriments o canvis en les prioritats empresarials, assegurant que el llenguatge segueixi sent rellevant i actualitzat durant tot el procés de desenvolupament.

Patrons de disseny tàctic en disseny basat en dominis (DDD)

En el disseny impulsat per dominis (DDD), els patrons de disseny tàctic són estratègies o tècniques específiques utilitzades per estructurar i organitzar el model de domini dins d'un sistema de programari. Aquests patrons ajuden els desenvolupadors a capturar eficaçment la complexitat del domini, alhora que afavoreixen el manteniment, la flexibilitat i l'escalabilitat.

Vegem alguns dels patrons clau de disseny tàctic a DDD:

1. Entitat

Una entitat és un objecte de domini que té una identitat i un cicle de vida diferents. Les entitats es caracteritzen pels seus identificadors únics i per l'estat mutable. Encapsulen el comportament i les dades relacionades amb un concepte específic dins del domini.

Per exemple, en una aplicació bancària, aBankAccount>L'entitat pot tenir propietats com el número de compte, el saldo i el propietari, juntament amb mètodes per dipositar, retirar o transferir fons.

2. Objecte de valor

Un objecte de valor és un objecte de domini que representa un valor conceptualment immutable. A diferència de les entitats, els objectes de valor no tenen una identitat diferent i normalment s'utilitzen per representar atributs o propietats de les entitats. Els objectes de valor són comparables per igualtat en funció de les seves propietats, més que de la seva identitat.

Per exemple, aMoney>L'objecte de valor pot representar una quantitat específica de moneda, encapsulant propietats com el tipus i la quantitat de moneda.

3. Agregat

• Un agregat és un clúster d'objectes de domini que es tracten com una unitat única per tal de garantir la coherència de les dades i la integritat transaccional.
• Els agregats consisteixen en una o més entitats i objectes de valor, amb una entitat designada com a arrel agregada.
• L'arrel de l'agregat serveix com a punt d'entrada per accedir i modificar l'estat intern de l'agregat.
• Els agregats imposen els límits de coherència dins del model de domini, garantint que els canvis als objectes relacionats es realitzin atòmicament.

Per exemple, en un sistema de comerç electrònic, anOrder>l'agregat pot consistir en entitats comOrderItem>iCustomer>, amb elOrder>entitat que serveix com a arrel agregada.

4. Repositori

• Un repositori és un mecanisme per abstraure la lògica de persistència i accés a dades del model de domini.
• Els repositoris proporcionen una interfície estandarditzada per consultar i emmagatzemar objectes de domini, amagant els detalls de com es recuperen o s'emmagatzemen les dades. Els repositoris encapsulen la lògica per traduir entre objectes de domini i mecanismes d'emmagatzematge de dades subjacents, com ara bases de dades o serveis externs.
• En desacoblar el model de domini de les preocupacions d'accés a les dades, els dipòsits permeten una major flexibilitat i manteniment.

Per exemple, aCustomerRepository>podria proporcionar mètodes per consultar i emmagatzemarCustomer>entitats.

5. Fàbrica

• Una fàbrica és una patró de creació s'utilitza per encapsular la lògica per crear instàncies d'objectes de domini complexos. Les fàbriques abstreuen el procés d'instanciació d'objectes, permetent als clients crear objectes sense necessitat de conèixer els detalls de la seva construcció.
• Les fàbriques són especialment útils per crear objectes que requereixen una lògica d'inicialització complexa o que impliquen diversos passos.

Per exemple, aProductFactory>podria ser responsable de crear instàncies deProduct>entitats amb configuracions per defecte.

6. Servei

• Un servei és un objecte de domini que representa un comportament o una operació que no pertany naturalment a cap entitat o objecte de valor específic.
• Els serveis encapsulen la lògica de domini que opera sobre diversos objectes o orquestra les interaccions entre objectes.
• Els serveis solen ser sense estat i se centren a realitzar tasques específiques o fer complir les regles del domini.

Per exemple, anOrderService>pot proporcionar mètodes per processar comandes, aplicar descomptes i calcular els costos d'enviament.

Beneficis del disseny basat en dominis (DDD)

• Comprensió compartida :
  • Fomenta la col·laboració entre experts del domini, desenvolupadors i parts interessades.
  • En fomentar una comprensió compartida del domini del problema a través del llenguatge omnipresent, els equips poden comunicar-se de manera més eficaç i garantir que el programari reflecteixi amb precisió les necessitats i els requisits de l'empresa.
• Centra't en el domini bàsic :
  • Ajuda als equips a identificar i prioritzar el domini bàsic de l'aplicació: les àrees del sistema que proporcionen més valor al negoci. En centrar els esforços de desenvolupament en el domini bàsic, els equips poden oferir una funcionalitat que abordi directament els objectius empresarials i diferenciï el programari dels competidors.
• Resiliència al canvi :
  • Fa èmfasi en el disseny de sistemes de programari que siguin resistents al canvi modelant el domini d'una manera que reflecteixi les complexitats i incerteses inherents al domini del problema.
  • En adoptar el canvi com a part natural del desenvolupament de programari, els equips poden respondre de manera més eficaç a les necessitats empresarials en evolució i a les condicions del mercat.
• Separació clara de preocupacions :
  • DDD fomenta una clara separació de les preocupacions entre la lògica del domini, les preocupacions d'infraestructura i les preocupacions de la interfície d'usuari. En aïllar la lògica del domini dels detalls tècnics i les preocupacions d'infraestructura, els equips poden mantenir un model de domini net i enfocat que sigui independent dels detalls específics d'implementació o de les opcions tecnològiques.
• Testabilitat millorada :
  • Fomenta l'ús d'objectes de domini amb límits i comportaments ben definits, facilitant l'escriptura de proves millors i enfocades que verifiquen la correcció de la lògica del domini.
  • En dissenyar sistemes de programari tenint en compte la provabilitat, els equips poden assegurar-se que els canvis a la base de codi són segurs i previsibles, reduint el risc d'introduir regressió o efectes secundaris no desitjats.
• Suport a regles empresarials complexes :
  • Proporciona patrons i tècniques per modelar i implementar regles i fluxos de treball complexos dins del model de domini.
  • En representar les regles empresarials de manera explícita al model de domini, els equips poden assegurar-se que el programari reflecteixi amb precisió les complexitats del domini empresarial i faci complir les restriccions i els requisits específics del domini.
• Alineació amb els objectius empresarials :
  • En última instància, té com a objectiu alinear els esforços de desenvolupament de programari amb les metes i objectius estratègics del negoci. En centrar-se a comprendre i modelar el domini del problema, els equips poden oferir solucions de programari que donen suport directament als objectius empresarials, impulsen la innovació i creen valor per a les parts interessades i els usuaris finals.

Reptes del disseny impulsat per dominis (DDD)

• Complexitat :
  • DDD pot introduir complexitat, especialment en dominis grans i complexos.
  • Modelar dominis empresarials complexos amb precisió requereix una comprensió profunda del domini i pot implicar fer front a l'ambigüitat i la incertesa. Gestionar aquesta complexitat de manera eficaç requereix una planificació acurada, col·laboració i experiència.
• Adopció lingüística ubiqua :
  • Establir i mantenir un llenguatge omnipresent (un vocabulari compartit que representi amb precisió els conceptes del domini) pot ser un repte. Requereix la col·laboració entre desenvolupadors i experts del domini per identificar i acordar els termes i els significats del domini.
  • Aconseguir un consens sobre el llenguatge omnipresent pot requerir superar les barreres de comunicació i conciliar les diferències de terminologia i perspectives.
• Alineació de context acotat :
  • En dominis grans i complexos, diferents parts del domini poden tenir models diferents i contextos limitats. Alinear aquests contextos limitats i garantir la coherència entre ells pot ser un repte.
  • Requereix una comunicació clara, col·laboració i coordinació entre els equips que treballen en diferents parts del domini per evitar inconsistències i conflictes.
• Complexitat tècnica :
  • La implementació eficaç dels principis i patrons de DDD pot requerir l'adopció de noves tecnologies, marcs i enfocaments arquitectònics. La integració de DDD amb sistemes existents o bases de codi heretades pot ser complexa i pot requerir refactoritzar o redissenyar el codi existent per alinear-se amb els principis de DDD.
  • Els reptes tècnics com ara el rendiment, l'escalabilitat i el manteniment s'han d'abordar amb cura per garantir l'èxit de l'adopció de DDD.
• Resistència al canvi :
  • Introduir el DDD pot trobar resistència dels membres de l'equip que estan acostumats als enfocaments de desenvolupament tradicionals o que perceben el DDD com massa complex o poc pràctic.
  • Superar la resistència al canvi requereix una comunicació, una educació i un lideratge efectius per demostrar els beneficis del DDD i abordar les preocupacions i l'escepticisme.
• Sobreenginyeria :
  • Hi ha un risc de sobreenginyeria quan s'apliquen DDD, on els equips se centren massa en modelar conceptes complexos de domini i introduir abstraccions o complexitat innecessàries. Aconseguir l'equilibri adequat entre simplicitat i expressivitat és crucial per evitar complicacions excessives en el disseny i la implementació.

Casos d'ús del disseny basat en dominis (DDD)

• Finances i Banca :
  • En el sector financer, el DDD es pot utilitzar per modelar instruments financers complexos, transaccions i requisits reguladors. En representar amb precisió conceptes de domini com ara comptes, transaccions i carteres, DDD ajuda a garantir la integritat i la coherència dels sistemes financers. També permet una millor gestió del risc, compliment i informes.
• Comerç electrònic i Retail :
  • Les plataformes de comerç electrònic sovint tracten conceptes de domini complexos, com ara catàlegs de productes, gestió d'inventaris, preus i comandes dels clients. DDD pot ajudar a modelar aquests conceptes de manera eficaç, habilitant funcions com ara recomanacions personalitzades, preus dinàmics i processament de comandes racionalitzat.
• Salut i Ciències de la Vida :
  • A l'assistència sanitària, el DDD es pot utilitzar per modelar registres de pacients, diagnòstics mèdics, plans de tractament i fluxos de treball sanitaris. En representar amb precisió conceptes de domini com ara la demografia dels pacients, les històries clíniques i els protocols clínics, el DDD permet el desenvolupament de sistemes robusts d'historial mèdic electrònic (EHR), plataformes d'imatge mèdica i aplicacions de telemedicina.
• Assegurança :
  • Les companyies d'assegurances gestionen diversos productes, pòlisses, reclamacions i processos de subscripció. DDD pot ajudar a modelar aquests conceptes de domini complexos, habilitant funcions com ara la gestió de polítiques, el processament de reclamacions, l'avaluació de riscos i l'anàlisi actuarial.
• Gestió immobiliària i immobiliària :
  • La gestió d'immobles i propietats implica la gestió de diverses propietats, arrendaments, llogaters, sol·licituds de manteniment i transaccions financeres. DDD pot ajudar a modelar aquests conceptes de domini de manera eficaç, habilitant funcions com ara llistats de propietats, gestió d'arrendaments, portals de llogaters i seguiment d'actius.

Exemple real de disseny basat en dominis (DDD)

Plantejament del problema

Diguem que estem desenvolupant una aplicació de transport anomenada RideX. El sistema permet als usuaris sol·licitar viatges, als conductors acceptar sol·licituds de viatges i facilita la coordinació de viatges entre usuaris i conductors.

subcadena de retall de javascript

Llenguatge omnipresent

1. Usuari : Es refereix a les persones que sol·liciten viatges a través de la plataforma RideX.
2. Conductor : Es refereix a les persones que ofereixen viatges als usuaris mitjançant la plataforma RideX.
3. Sol·licitud de viatge : representa la sol·licitud d'un usuari per a un viatge, especificant detalls com ara la ubicació de recollida, la destinació i les preferències de viatge.
4. Passejada : representa una única instància d'un viatge, inclosos detalls com ara els llocs de recollida i lliurament, la tarifa i la durada.
5. Estat del viatge : representa l'estat actual d'un viatge, com ara Sol·licitat, Acceptat, En curs o Completat.

Contextos acotats

1. Context de gestió del viatge : Responsable de gestionar el cicle de vida dels viatges, incloses les sol·licituds de viatges, les assignacions de viatges als conductors i les actualitzacions de l'estat dels viatges.
2. Context de gestió d'usuaris : Gestiona l'autenticació, el registre i les funcions específiques de l'usuari, com ara l'historial de viatges i els mètodes de pagament.
3. Context de gestió del conductor : Gestiona l'autenticació del conductor, el registre, l'estat de disponibilitat i les funcions específiques del conductor, com ara els guanys i les puntuacions.

Entitats i objectes de valor

1. Entitat usuari : representa un usuari registrat de la plataforma RideX, amb propietats com l'identificador d'usuari, correu electrònic, contrasenya i informació de pagament.
2. Entitat conductora : representa un conductor registrat a la plataforma RideX, amb propietats com l'identificador del conductor, els detalls del vehicle i l'estat del conductor.
3. Entitat de sol·licitud de viatge : representa la sol·licitud d'un usuari d'un viatge, incloses propietats com ara l'identificador de sol·licitud, la ubicació de recollida, la destinació i les preferències de viatge.
4. Entitat Ride : representa una única instància d'un viatge, incloses propietats com ara l'identificador del viatge, els llocs de recollida i lliurament, la tarifa i l'estat del viatge.
5. Objecte de valor d'ubicació : representa una ubicació geogràfica, amb propietats com la latitud i la longitud.

Àrids

1. Ride Agregat : consta de l'entitat de viatge com a arrel agregada, juntament amb entitats relacionades com ara les entitats de sol·licitud de viatge, usuari i conductor. El Ride Agregate encapsula la lògica per gestionar el cicle de vida d'un viatge, inclosa la gestió de les sol·licituds de viatge, l'assignació de conductors i l'actualització de l'estat del viatge.

Repositori

1. Repositori Ride : Proporciona mètodes per consultar i emmagatzemar entitats relacionades amb els viatges, com ara la recuperació de detalls del viatge, l'actualització de l'estat del viatge i l'emmagatzematge de dades relacionades amb el viatge a la base de dades.

Serveis

1. Servei d'assignació de viatges : Responsable d'assignar els conductors disponibles a les sol·licituds de viatge en funció de factors com ara la disponibilitat del conductor, la proximitat al lloc de recollida i les preferències de l'usuari.
2. Servei de pagament : Gestiona el processament de pagaments per a viatges completats, calcula les tarifes, processa els pagaments i actualitza la informació de pagament de l'usuari i del conductor.

Esdeveniments de domini

1. RideRequestedEvent : representa un esdeveniment activat quan un usuari sol·licita un viatge, que conté informació com ara els detalls de la sol·licitud de viatge i l'identificador d'usuari.
2. RideAcceptedEvent : representa un esdeveniment activat quan un conductor accepta una sol·licitud de viatge, que conté informació com ara l'identificador del viatge, l'identificador del conductor i la ubicació de recollida.

Exemple d'escenari

1. Usuari que sol·licita un viatge : un usuari sol·licita un viatge proporcionant la seva ubicació de recollida, destinació i preferències de viatge. RideX crea una nova entitat de sol·licitud de viatge i activa un RideRequestedEvent.
2. Conductor que accepta un viatge : Un conductor accepta una sol·licitud de viatge de la plataforma RideX. RideX actualitza l'estat del viatge a Accepted, assigna el conductor al viatge i activa un RideAcceptedEvent.
3. Passeig en curs : l'usuari i el conductor coordinen el viatge, amb la transició de l'estat del viatge d'Acceptat a En curs un cop el conductor arriba al lloc de recollida.
4. Finalització del viatge : Després d'arribar a la destinació, l'estat del viatge s'actualitza a Finalitzat. RideX calcula la tarifa, processa el pagament i actualitza la informació de pagament de l'usuari i del conductor en conseqüència.