<!--
rating: ⭐️⭐️⭐️ // 1 to 3 stars
date: 2023 // when started reading
read: 2023 // when finished reading
status: undefined, backlog, to read, reading, completed, stopped
-->
# Untitled
by [[{{author}}]]
## Summary
<!-- No more than a couple paragraphs summarizing this BOOK -->
{{description}}
## Table of Contents
## Notes
### Capitol 1: Analyzing Business Domains
- **Importància d’entendre el negoci abans de codificar**
Per dissenyar una solució efectiva cal comprendre l’estratègia i els objectius de l’empresa: què fa, per què ho fa i quin valor n’extreu. Això defineix el problema que volem resoldre amb el software.
- **Business Domain**
L’àmbit principal d’activitat d’una empresa, és a dir, el servei o producte que ofereix als clients (p. ex., FedEx: missatgeria; Starbucks: cafè; Walmart: retail).
- **Subdomain**
Àrea més fina de responsabilitat dins del Business Domain. Cada subdomini és un “bloc de construcció” que interactua amb la resta per assolir els objectius globals de l’empresa.
- **Tipus de Subdomains**
1. **Core Subdomain**
- Activitat distintiva que atorga avantatge competitiu.
- Altament complex i volàtil: evoluciona constantment per mantenir el lideratge.
- Implementat internament amb les millors pràctiques d’enginyeria.
2. **Generic Subdomain**
- Problemes comuns a totes les empreses (autenticació, pagaments, xifrat).
- Complexos d’implementar però resolts "off-the-shelf".
- Poca o nul·la aportació competitiva: es compren o adopten solucions existents.
3. **Supporting Subdomain**
- Funcions de suport sense avantatge competitiu (CRUDs, ETL, integracions).
- Lògica senzilla i poc volàtil.
- Es pot desenvolupar internament de forma àgil o fins i tot externalitzar-lo.
- **Comparativa estratègica**
Cada tipus de subdomini guia decisions clau de disseny i organització d’equips:
|Subdomain|Avantatge competitiu|Complexitat|Volatilitat|Implementació|
|---|---|---|---|---|
|Core|Sí|Alta|Alta|In-house|
|Generic|No|Alta|Baixa|Comprar/Adoptar|
|Supporting|No|Baixa|Baixa|In-house/Outsource|
- **Volatilitat i evolució**
- Els **Core** canvien sovint: és on s’inverteix innovació i optimització contínua.
- Els **Generic** només varien per manteniment (bugs, seguretat).
- Els **Supporting** evolucionen molt poc i amb baix impacte de negoci.
- **Estratègia de solució**
- **Core**: equip expert intern, tècniques avançades, fàcil de refinar.
- **Generic**: comprar o utilitzar open-source, aprofitar solucions battle-tested.
- **Supporting**: implantar ràpid amb frameworks RAD, formar talent júnior, possible outsourcing.
- **Identificació de límits de subdomini**
- Partir del mapa organitzatiu (departaments) i refinar fins a trobar use cases coherents i actors comuns.
- Parar de fer “drill-down” quan el refinament no aporta més decisions de disseny útils.
- **Domain Experts**
Són els veritables coneixedors del negoci (no tècnics ni analistes): són els que generen i validen els requisits, i col·laboren per traduir el seu model mental en un llenguatge ubiqüitari.
En conjunt, aquest capítol dóna les eines per mapear l’estructura del negoci en subdominis estratègics, sent la base per aplicar després patrons DDD tant a nivell **strategic** (Bounded Contexts, Context Maps) com **tactical** (Aggregates, Domain Events, etc.).
### Capitol 2: Discovering DomainKnowledge
Aquest capítol subratlla que, abans de programar, cal entendre a fons com funciona l’empresa: la seva estratègia, objectius i valor que busca aportar. Defineix el **Business Domain** com l’àrea principal del que fa l’empresa (el servei o producte que ofereix) i els **Subdomains** com els seus blocs funcionals interns. Distingim tres tipus:
- **Core Subdomain:** àrees distintives, complexes i volàtils que donen avantatge competitiu; desenvolupament intern amb tècniques avançades.
- **Generic Subdomain:** problemes comuns i difícils (p. ex., autenticació, pagaments) però resolts amb solucions “off-the-shelf”; s’adopten productes existents.
- **Supporting Subdomain:** funcionalitats senzilles de suport (CRUD, ETL, integracions), poc canviants i sense valor diferencial; es poden fer internament de manera ràpida o externalitzar.
Aquests tipus guien decisions de disseny, organització d’equips i estratègia d’implementació. La **volatilitat** (freqüència de canvis) i la **complexitat** varien segons el tipus, de manera que convé:
- Invertir els millors talents i recursos en els Core.
- Comprar o adoptar solucions per als Generic.
- Utilitzar eines ràpides i formació de perfil més júnior per als Supporting.
Per identificar subdominis, partim de l’estructura organitzativa i refinem fins a casos d’ús coherents, aturant-nos quan no aporta més valor estratègic. Finalment, els **Domain Experts** (experts de negoci) validen i enriqueixen el model, traduint el seu coneixement en un llenguatge compartit que sustenta tant el disseny estratègic (Bounded Contexts, Context Maps) com el tàctic (Aggregates, Events).
### Capitol 3: Managing Domain Complexity
Aquí tens un resum del **Capítol 3: Managing Domain Complexity**, amb els conceptes principals i una breu explicació de cadascun:
- **Modelització inconsistent**
Els experts de negoci de diferents àrees poden tenir visions contradictòries del mateix concepte (per exemple, el “lead” és només un esdeveniment al màrqueting però un procés de llarg recorregut a vendes). Intentar un únic model universal condueix a solucions sobre- o infra-enginyeritzades.
- **Bounded Context**
Patró que resol les ambigüitats: es divideix el llenguatge ubiqüitari en múltiples llenguatges més petits, cadascun limitat al seu **context explícit**. Dins de cada bounded context un terme té un únic significat coherent.
- **Limitacions del model**
Un model existeix sempre dins d’un límit: si es desborda, esdevé una còpia inabastable de la realitat. Seleccionar on traçar la frontera (el bounded context) és part essencial del disseny, com triar el tipus de mapa adequat al seu propòsit.
- **Ubiquitous Language refinat**
El llenguatge ubiqüitari no ha de ser global, sinó “ubiquitari dins del seu context”: només cal que sigui coherent i precís dins dels límits definits.
- **Granularitat de contextos**
Els bounded contexts poden ser amplis (cobrint un subdomini complet) o petits (descomposar-los per problemes més concrets). Cal equilibrar la mida pel cost d’integració versus la coherència interna.
- **Subdomains vs. Bounded Contexts**
- **Subdomains**: àrees de negoci descobertes (core, supporting, generic), definides per l’estratègia de l’empresa.
- **Bounded Contexts**: límits de model dissenyats per ajustar el software al projecte, basats en la consistència del llenguatge i les necessitats d’implementació.
- **Fronteres físiques i d’ownership**
Cada bounded context hauria d’implementar-se com un component o servei independent (tecnologia, desplegament, versió). Ha de tenir un únic equip responsable, evitant dues àrees treballant sobre el mateix model implícit.
- **Exemples de contexts reals**
Són omnipresents: des de definicions botàniques vs culinàries de “tomàquet” fins als models de gravetat de Newton vs Einstein. Cada àmbit té el seu propi model útil pel seu propòsit.
En conjunt, aquest capítol mostra com gestionar la complexitat del domini subdividint-lo per contextos coherents, garantint que cada model i llenguatge sigui consistent, proveït pel seu equip i integrat mitjançant protocols explícits.
### Capítol 4: Integrating Bounded Contexts
Aquí tens els conceptes principals del **Capítol 4: Integrating Bounded Contexts**, amb una breu explicació de cada patró:
- **Contracts entre contexts**
Quan els bounded contexts interactuen, cal definir **contractes explícits** que tradueixin les diferències de model i llenguatge entre ells.
- **Cooperació (Cooperation)**
Equips amb alta comunicació i objectius depenents col·laboren de manera fluida.
- **Partnership**: integració ad hoc i bidireccional, amb sincronitzacions constants i CI compartida.
- **Shared Kernel**: comparteixen un petit nucli de codi/model que es manté conjuntament, reduint duplicacions però exigint coordinació i tests d’integració.
- **Client-Proveïdor (Customer–Supplier)**
Un context “upstream” ofereix un servei i el “downstream” el consumeix.
- **Conformist**: el downstream accepta el model del proveïdor tal qual (“take it or leave it”).
- **Anticorruption Layer**: el downstream construeix una capa de traducció per adaptar el model del proveïdor al seu propi model.
- **Open-Host Service**: el proveïdor exposa un “published language” orientat al consumidor, desacoplant el seu model intern de la interfície pública i fins i tot oferint múltiples versions per migracions graduals.
- **Separate Ways**
Quan col·laborar costa més que duplicar, cada context implementa localment la funcionalitat (normalment en subdominis genèrics), evitant la complexitat de la integració.
- **Context Map**
Diagrama que mostra tots els bounded contexts i els patrons d’integració entre ells, oferint visió de:
1. **Disseny d’alt nivell** (quins serveis/subsistemes hi ha).
2. **Patrons de comunicació** (quins equips col·laboren íntimament i quins opten per capes d’anticorruption o Separate Ways).
3. **Problemes organitzatius** (on hi ha friccions en la integració).
Aquestes estratègies permeten gestionar tant la **coherència interna** de cada model como la **flexibilitat** i **resiliència** en les seves interaccions.
### Capitol 5: Implementing Simple Business
Aquí tens un resum dels **conceptes més importants** del **Capítol 5: Implementing Simple Business Logic**:
- **Importància de la lògica de negoci**
És el cor del software: pot tenir la millor UI o la base de dades més ràpida, però si no resol problemes de negoci, no té valor.
- **Patterns per lògica senzilla**
Quan els subdominis són de suport o genèrics i la complexitat és baixa, cal optar per solucions senzilles que minimitzin l’overhead:
1. **Transaction Script**
- Organitza la lògica en procediments on cada “script” gestiona una única transacció (un cas d’ús).
- **Requisit clau**: comportament transaccional atòmic — o tot s’executa o tot es desfa (rollback).
- **Avantatges**: fàcil d’entendre i de posar en marxa; ajustat a processos ETL o CRUD senzills.
- **Riscos comuns**: corrupció de dades si no s’abasta tota la seqüència en una única transacció, especialment en entorns distribuïts (publicació de missatges, múltiples bases de dades, notificacions clients).
2. **Active Record**
- Cada fila o estructura complexa del model de dades es representa com un objecte amb mètodes CRUD integrats (`save()`, `delete()`, etc.).
- **Encapsula** el mapping objecte-relacional dins de l’objecte mateix.
- **Útil** quan la lògica és senzilla però cal treballar amb estructures de dades més riques (relacions 1-N, N-N).
- **Limitacions**: quan la lògica de negoci creix, aquests objectes tendeixen a convertir-se en anèmic domains o en “Big Ball of Mud”.
- **Quan usar-los**
- **Subdominis de suport** (CRUD, ETL) o **generic subdomains** (integracions senzilles, capa d’anticorruption).
- **Mai** per a **core subdomains**, on la complexitat i la volatilitat obliguen a patrons més sofisticats (Domain Model, Aggregate, Domain Events).
- **Be Pragmatic**
En entorns d’alta escala, pot ser acceptable relaxar garanties de consistència (p. ex. pèrdua o duplicació de <0,01% d’esdeveniments), sempre avaluant el risc i l’impacte de negoci.
En conjunt, aquests dos patrons —**Transaction Script** i **Active Record**— proporcionen una base lleugera i de ràpida adopció per a lògica de negoci simple, evitant la complexitat innecessària quan el domini no ho requereix.
### Capitol 6: Tackling Complex Business Logic
Aquí tens un resum dels **conceptes més importants** del **Capítol 6: Tackling Complex Business Logic**:
- **Domain Model Pattern**
Enfronta dom̀inis amb lògica encreuçada i regles invariables complexes (invariants), com els fluxos de vida de tiquets de suport, on cal aplicar múltiples regles i temps límit de resposta.
- **Plain Old Objects**
El model ha d’estar lliure de dependències tecnològiques: “POCOs/POJOs” que encapsulen només lògica de negoci i dades, sense cridar directament a bases de dades o frameworks.
- **Value Objects**
- Immutables i identificats pels seus valors (no per ID).
- Centralitzen validació i comportaments sobre els seus valors (p. ex. conversió d’unitats, mescles de colors, parsers de telèfons o correus).
- El·liminen l’“obsessió per primitius” i fan el codi més expressiu i segur.
- **Entities**
- Necessiten un **ID** explícit immutable per distingir instàncies.
- Representen actors o conceptes que canvien amb el temps (per exemple, un usuari, un tiquet).
- **Aggregates**
- Agrupen una jerarquia d’entitats i value objects sota una única **Aggregate Root**.
- Actuen com a **límits de consistència** i **transacció atòmica**: tots els canvis d’un agregat es validen i persisteixen com una sola unitat.
- Exposen **comandes** (mètodes públics) que encapsulen tota la lògica i invariants.
- Gestionen **concorrència optimistic** mitjançant camps de versió per evitar sobreescriptures.
- **Domain Events**
- Mensatges en passat (“TicketEscalated”, “MessageReceived”) que relaten fets rellevants ocorreguts dins de l’agregat.
- S’acumulen durant l’execució de comandes i després es publiquen per notificar altres components o sistemes.
- **Domain Services**
- Objets sense estat que implementen lògica de negoci que no encaixa dins d’un únic agregat (per exemple, càlcul de terminis de resposta basat en polítiques de departament i horaris).
- Coordinadors de diverses fonts de domini, però sense violar la regla d’una transacció per agregat.
- **Gestió de la complexitat**
- Reduir els **graus de llibertat** encapsulant invariants dins d’agregats i value objects.
- Fer el model **previsible** i **controlable** mitjançant quotes úniques de responsabilitat i fronteres clares.
En conjunt, el **Domain Model Pattern** i els seus blocs tàctics (value objects, entities, aggregates, domain events i domain services) són la forma recomanada per implementar lògica de negoci complexa, mantenint la coherència, testabilitat i evolució del sistema.
### Capitol 8: Architectural Patterns
Aquí tens els aspectes més importants del **Capítol 8: Architectural Patterns**, amb una breu explicació de cada concepte:
- **Perill de difusió de la lògica de negoci**
Sense fronteres clares, la lògica de negoci acaba mesclada amb la capa d’UI, la persistència o els integracions, cosa que dificulta els canvis i eleva el cost de manteniment.
- **Patró de l’arquitectura en capes (Layered)**
1. **Presentation Layer**: màquina d’entrada/sortida (GUI, API, subscripcions a missatges).
2. **Business Logic Layer**: cor del sistema, on viuen els patrons tàctics (Transaction Script, Active Record, Domain Model).
3. **Data Access Layer**: persistència i integracions externes.
- **Variació**: **Service/Application Layer** com a façana per l’UI, encapsulant transaccions i orquestració.
- **Ús**: encaixa bé amb Transaction Script i Active Record, però força la lògica de negoci a dependre de la infraestructura, cosa que complica l’ús d’un Domain Model pur.
- **Ports & Adapters (Hexagonal/Clean/Onion)**
- **Principi**: invertir dependències perquè el **núcli de negoci** no conegui cap infraestructura.
- **Ports**: interfícies cap al món exterior (per ex., repositoris, missatgeria, clients HTTP).
- **Adapters**: implementacions concretes d’aquests ports (ORM, col·leccions en memòria, brokers de missatges).
- **Application Layer** actua de façana d’entrada (use cases), mentre el **Core Layer** conté lògic pur.
- **Ús**: ideal per a Domain Model i Event Sourcing, perquè aïlla completament la lògica de negoci de qualsevol framework o base de dades.
- **CQRS (Command–Query Responsibility Segregation)**
- **Separació de models**:
- **Command Model** (fonamental, fortament consistent) per executar operacions (commands) i aplicar invariants.
- **Read Models** (projeccions) optimitzats per a consultes, poden viure en BD diferents (document, columnar, cercador).
- **Projeccions síncrones**: polling amb checkpoint sobre l’OLTP.
- **Projeccions asíncrones**: subscripció a esdeveniments o missatges; més escalable però més propens a incoherències si no es maneja bé l’ordre o la duplicació.
- **Regla**: els commands poden retornar dades del model consistent; no cal esperar a la projecció per poder mostrar resultats immediats.
- **Scopes i modularitat**
- No cal aplicar un sol patró arreu: cada **subdomini** (slice vertical) pot triar l’arquitectura que millor s’ajusti (ETL senzill amb capa, NUCLI de negoci complex amb Hexagonal, lectura massiva amb CQRS).
- Aquestes **slices** permeten evitar “Big Ball of Mud” i mantenir el codi organitzat per responsabilitats.
En conjunt, aquest capítol t’ensenya a triar i combinar patrons arquitectònics segons la complexitat de la lògica de negoci i els requisits no funcionals, assegurant que la base de codi sigui clara, testable i fàcil d’evolucionar.
### Capitol 9: Communication Patterns
Aquí tens un resum dels **conceptes més importants** del **Capítol 9: Communication Patterns**, amb una breu explicació de cadascun:
- **Model Translation**
Quan dos bounded contexts no comparteixen el mateix model, cal traduir missatges/protocols:
- **Stateless**: traducció “al vol” mitjançant un proxy o API Gateway (síncron) o un intermediar i filtratge de missatges (asíncron).
- **Stateful**: quan cal agregar o unificar dades, es requereix emmagatzematge local per acumular peticions en lots o combinar múltiples fonts en un sol model (interchange context, backends‐for‐frontend, pipe & filter).
- **Outbox Pattern**
Per publicar **domain events** de forma fiable:
1. Durant la mateixa transacció que actualitza l’agregat, escriu els nous events en una taula “outbox”.
2. Un “relay” (polling o log tailing) recull els events pendents i els publica al message bus.
3. Marca o elimina els events ja publicats.
Això garanteix “at least once” i evita inconsistències entre base de dades i missatgeria.
- **Saga**
Processos de negoci **long‐running** que orquestren **varis aggregates** de manera eventualment consistent:
- Són disparats per domain events i emeten comandes a altres components.
- Gestionen fluxos lineals senzills sense estat propi.
- Compensa errors amb accions inverses si cal.
- **Process Manager**
Com la saga però per fluxos de negoci **complexos** i ramificats:
- Té **estat** propi (persistit) que manté el context i decisions (if/else).
- S’instancia explícitament i fa de “coordinador” central, disparant comandes condicionals segons els esdeveniments rebuts.
—
Aquestes patterns permeten connectar bounded contexts i aggregates de manera robusta, mantenint la consistència interna i l’evolució independent dels components, mitjançant traduccions controlades, publicació fiable d’esdeveniments i orquestració de processos de negoci distribuïts.
## Quotes
<!-- Notable quotes with reference to their page or location -->
## Bibliography
> `= this.bibliography`
---
## Tasks
<!-- What remains to be done with this note? -->
-
## References
<!-- Links to pages not referenced in the content -->
-