<!--
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
#### C11 DIP
- **Definició del DIP**
El principi estableix dos punts clau:
1. Els **mòduls d’alt nivell** no han de dependre de mòduls de baix nivell; tots dos han de dependre d’**abstraccions**.
2. Les **abstraccions** no han de dependre de detalls; són els **detalls** els que han de dependre de les abstraccions .
- **Motivació**
Sense DIP, els components de negoci (casos d’ús, entitats) queden fortament lligats a la base de dades, la UI o altres frameworks. Això dificulta canviar qualsevol detall extern sense afectar el nucli de lògica .
- **Com aplicar-lo**
1. **Extraure interfícies**: defineix les operacions que necessita el mòdul d’alt nivellcom a interfícies (repositoris, serveis externs, factories).
2. **Injecció de dependències**: els detalls d’implementació (ORM, HTTP clients, adaptadors) implementen aquestes interfícies i s’injecten al nucli mitjançant constructors, fàbriques o un contenidor de DI.
3. **Llindar de dependències**: traça fronteres entre capes, de manera que les classes interiors només coneguin les interfícies externes i mai classes concretes .
- **Patrons habituals**
- **Repository Pattern** per desacoblar l’accés a dades.
- **Service Interfaces** per encapsular crides a serveis externs o infraestructures.
- **Factoria o Contenidor de DI** per compondre les implementacions concretes en temps d’arrencada.
- **Beneficis**
— **Flexibilitat**: canviar o substituir frameworks i detalls externs sense tocar la lògica de negoci.
— **Testabilitat**: els mòduls d’alt nivell es poden provar aïlladament mitjançant mocks o stubs de les interfícies.
— **Mantenibilitat**: el codi queda menys acoblat i més clar en la seva separació de responsabilitats.
#### C15: Què és arquitectura?
- **Arquitectura vs. disseny**
– El **disseny** sol referir-se a decisions de detall (“How will aquest mètode funcionar?”), mentre que l’**arquitectura** engloba les decisions de més alt nivell sobre l’estructura global i la divisió en components.
- **Decisions “significatives”**
– L’autor defineix l’arquitectura com el conjunt de decisions crítiques que afecten la durabilitat, la flexibilitat i la mantenibilitat del sistema. Són aquelles que, si s’hi aplica un canvi, obligarien a reescriure grans parts del codi.
- **Metàfora de l’edifici**
– Igual que en edificació hi ha “planells” generals (fundacions, estructura, canals de servei) separats de detalls com acabats i colors, en software distingim les **parts arquitectòniques** (polítiques, regles de dependència, fronteres entre mòduls) dels **detalls tecnològics** (frameworks, bases de dades, UI).
- **Independència de la lògica de negoci**
– L’arquitectura ha de protegir la **regla d’inversió de dependències**: els nivells exteriors (bases de dades, UI, infraestructures) depenen de la lògica de negoci (entitats i casos d’ús), no al revés. Això assegura que els canvis tecnològics no facin malbé la capa central.
- **Cercles concèntrics**
– Presenta el model de capes en forma de cercles:
1. **Entities** (dins, més estables)
2. **Use Cases** o casos d’ús
3. **Interface Adapters**
4. **Frameworks & Drivers** (fora, més canviants)
– La dependència ha d’apuntar sempre cap al centre.
- **Boundary Anatomy**
– Cada línia divisòria o **boundary** entre capes exigeix un **contracte** clar (una interfície, un adaptador, un mapeig), evitant fuites de detalls interns.
- **Durabilitat**
– Una bona arquitectura sobreviu als canvis constants en tecnologies i frameworks, perquè el cor del sistema—les entitats i regles de negoci—queda aïllat.
#### C16: Independència
- **Independència de Frameworks**
Els frameworks (Spring, Rails, ORM, etc.) són una eina, no el cor de l’aplicació. La lògica de negoci ha de poder funcionar sense dependre’n, de manera que puguis canviar o actualitzar el framework sense afectar les regles centrals.
- **Independència de la Interfície d’Usuari**
La capa de UI (web, mòbil, CLI…) ha d’estar totalment separada de la lògica de negoci. Això permet canviar l’UI (redisseny, proves noves tecnologies) sense tocar els casos d’ús ni les entitats.
- **Independència de la Base de Dades**
El teu model i els teus casos d’ús no han de dependre d’una base de dades concreta (SQL, NoSQL). S’utilitzen interfícies (repositoris) perquè la implementació concreta pugui substituir-se fàcilment.
- **Independència dels Agents Externs**
Tant fàbriques externes com sistemes de missatgeria, serveis web, APIs de tercers, etc. queden relegats a la vora de l’arquitectura. La lògica principal funciona amb abstraccions, i aquests detalls s’afegeixen mitjançant adaptadors.
- **Boundaries i Contractes Clars**
Cada línia divisòria entre capes requereix un contracte explícit (una interfície o adaptador). Això evita “fuites” de dependències i manté el centre del sistema net de tècnicismes externs.
- **Testabilitat i Automatisme**
Gràcies a aquesta independència, pots provar entitats i casos d’ús amb simples tests de unitat, sense necessitat de mockar frameworks o components externs, accelerant el feedback i millorant la qualitat.
- **Direcció de Dependències**
Les dependències sempre apunten cap al centre: de l’exterior (UI, DB, frameworks) cap a l’interior (casos d’ús, entitats). Aquesta inversió de dependències és clau per protegir el nucli de negoci.
- **Beneficis Clau**
— Facilitat per canviar tecnologies sense reescriure lògica de negoci
— Millor mantenibilitat i menor risc de regressions
— Equips més àgils, ja que poden treballar en paral·lel a diferents capes
— Codi més net i clar, perquè l’arquitectura “crida” el propòsit de l’aplicació
En conjunt, la independència garanteix que la part més valuosa del sistema —les regles de negoci— quedi protegida i que l’aplicació sigui flexible davant els canvis constants en tecnologies i requisits.
#### C17: Boundaries: Drawing Lines
- **Dibuixar límits al voltant dels detalls de baix nivell**
Es tracta de separar clarament la **lògica de negoci** (núcli) dels detalls com la base de dades o la interfície d’usuari, posant aquests darrers “darrere d’una interfície” per aplicar el principi d’inversió de dependències. D’aquesta manera, el nucli de la teva aplicació no coneix ni depèn directament de com s’implementen aquests detalls [blog.vranec.com](https://blog.vranec.com/2017/10/notes-about-clean-architecture-book.html?utm_source=chatgpt.com).
- **Eixos de canvi (Axis of Change)**
Els límits s’han de traçar allà on hi hagi components que **canvien per diferents motius o ritmes** (per exemple, el GUI canvia pel disseny, la base de dades per requisits de rendiment). Això evita que un canvi en un component “contamini” el nucli [codingblocks.net](https://www.codingblocks.net/podcast/clean-architecture-the-art-of-drawing-lines/?utm_source=chatgpt.com).
- **Decisions retardades (Deferred Decisions)**
L’arquitectura ha de permetre **posposar** decisions tecnològiques (triar MySQL, un framework web, un broker de missatges, etc.) fins que siguin absolutament necessàries, mantenint el sistema flexible i evitant treballs innecessaris prematurs [alexmanrique.com](https://alexmanrique.com/blog/books/2020/11/15/clean-architecture-book-summary.html?utm_source=chatgpt.com).
- **Plugins i inversió de dependències**
Els components externs (GUI, BD, serveis externs) es tracten com a **plugins**: el nucli defineix una **abstracció** i són ells qui l’implementen. Això significa que la dependència sempre apunta **cap al centre** (Business Rules) i mai al revés [blog.vranec.com](https://blog.vranec.com/2017/10/notes-about-clean-architecture-book.html?utm_source=chatgpt.com).
- **Escala de límits**
Un mateix principi s’aplica tant dins d’un **monòlit** (mòduls, paquets, DLLs) com en **processos locals** o **serveis distribuïts**. Sigui quin sigui el grau de separació física, la idea és preservar la mateixa estratègia de límits i dependències cap al nucli [blog.vranec.com](https://blog.vranec.com/2017/10/notes-about-clean-architecture-book.html?utm_source=chatgpt.com).
#### C18: Boundary Anatomy
- **Boundary Anatomy**
L’arquitectura d’un sistema es defineix pels seus components i pels límits (“boundaries”) que els separen.
- **Boundary Crossing**
A temps d’execució, travessar un límit és simplement que una funció en un component en cridi una altra en un component diferent, transferint-hi dades. La clau és gestionar les dependències de codi font perquè, quan un mòdul canviï, no calgui recompilar o redeployar tot el sistema [Papiro](https://www.papiro-bookstore.com/wp-content/uploads/2021/12/Clean-Architecture.pdf?utm_source=chatgpt.com).
- **The Dreaded Monolith**
Encara que tot estigui en un sol executable (monòlit), és possible mantenir-hi fronteres semàntiques a nivell de codi (mòduls, paquets) i aplicar el principi d’inversió de dependències per aïllar detalls de baix nivell darrera d’interfícies [Papiro](https://www.papiro-bookstore.com/wp-content/uploads/2021/12/Clean-Architecture.pdf?utm_source=chatgpt.com).
- **Deployment Components**
Separar el monòlit en biblioteques o components (DLLs, JARs, Nuget) permet desplegar només les parts que han canviat, mantenint encara una estreta comunicació mitjançant trucades de mètode [Papiro](https://www.papiro-bookstore.com/wp-content/uploads/2021/12/Clean-Architecture.pdf?utm_source=chatgpt.com).
- **Threads**
Dins d’un mateix procés, els límits també existeixen entre threads: cada thread pot accedir a mòduls compartits, però hem de controlar l’accés concurrent i usar abstractions per evitar fugides de dependències de negoci cap a codi de sincronització [Papiro](https://www.papiro-bookstore.com/wp-content/uploads/2021/12/Clean-Architecture.pdf?utm_source=chatgpt.com).
- **Local Processes**
Componentitzar per mitjà de processos separats en la mateixa màquina ofereix una frontera més forta que el monòlit o les biblioteques: la comunicació s’executa via IPC, cosa que encareix el cost de crida però reforça l’aïllament [Papiro](https://www.papiro-bookstore.com/wp-content/uploads/2021/12/Clean-Architecture.pdf?utm_source=chatgpt.com).
- **Services**
Quan els components són serveis independents en xarxa, obtens el límit més fort: la comunicació passa per la xarxa, és la més costosa i lenta, però permet desplegar i escalar cada servei de manera autònoma [Papiro](https://www.papiro-bookstore.com/wp-content/uploads/2021/12/Clean-Architecture.pdf?utm_source=chatgpt.com).
- **Conclusió**
La majoria de sistemes utilitzen més d’una estratègia de límits (per exemple, serveis compostos per JARs interns). És important triar el nivell de separació adequat segons el trade-off entre latència, couplage i autonomia de desplegament [Papiro](https://www.papiro-bookstore.com/wp-content/uploads/2021/12/Clean-Architecture.pdf?utm_source=chatgpt.com).
#### C19: Policy and Level
- **El sistema com a declaració de polítiques**
Un sistema de software és, essencialment, una **expressió de polítiques**: transforma entrades en sortides mitjançant una sèrie de regles i validacions. Aquestes polítiques es poden descompondre en fragments més petits (per exemple, regles de negoci, validacions de dades), i l’arquitectura ha de separar-les segons els motius i la freqüència amb què canvien [Bookey](https://www.bookey.app/book/clean-architecture?utm_source=chatgpt.com)[Medium](https://medium.com/%40mammimia/clean-architecture-part-iv-architecture-5eee3cb5656a?utm_source=chatgpt.com).
- **Nivells de política (Levels)**
Un **nivell** determina la **distància** d’una política respecte de les entrades i sortides del sistema.
- Polítiques de **nivell alt**: allunyades d’entrades/sortides, canvien poc (p. ex., regles de negoci estratègiques).
- Polítiques de **nivell baix**: pròximes a l’I/O, canvien sovint (p. ex., validacions específiques, accés a dades). [Bookey](https://www.bookey.app/book/clean-architecture?utm_source=chatgpt.com)[Medium](https://medium.com/%40mammimia/clean-architecture-part-iv-architecture-5eee3cb5656a?utm_source=chatgpt.com).
- **Agrupació per nivell**
Les polítiques que canvien pels mateixos motius i al mateix ritme s’ajunten en el **mateix component**. Així, cada component representa un conjunt de regles homogeni en termes de canvi, facilitant-ne l’evolució i el manteniment [Medium](https://medium.com/%40mammimia/clean-architecture-part-iv-architecture-5eee3cb5656a?utm_source=chatgpt.com).
- **Dependències dirigides cap a polítiques d’alt nivell**
L’arquitectura ha de formar un **graf dirigit sense bucles**, on els nodes són components de polítiques del mateix nivell i les arestes indiquen dependències de codi. Les dependències sempre han d’apuntar **des de components de nivell baix** (detalls tècnics) **cap a components de nivell alt** (polítiques de negoci) [Bookey](https://www.bookey.app/book/clean-architecture?utm_source=chatgpt.com)[Medium](https://medium.com/%40mammimia/clean-architecture-part-iv-architecture-5eee3cb5656a?utm_source=chatgpt.com).
- **Beneficis de separar per nivell**
— **Durabilitat**: les parts centrals (nivell alt) queden protegides de canvis freqüents en detalls.
— **Claredat**: traçar fronteres segons nivell ajuda a identificar quin codi és estratègic i quina és pura infraestructura.
— **Flexibilitat**: pots reemplaçar tecnologies de nivell baix sense afectar la lògica de negoci[](https://www.bookey.app/book/clean-architecture?utm_source=chatgpt.com)
#### C20: Business rules
- **Regles de negoci (Business Rules)**
Són les normes i procediments que fan o estalvien diners a l’empresa, independentment de si s’executen manualment o automàticament. Aquestes són les **Regles Crítiques** i sempre han d’existir, estiguin o no informatitzades [bespoyasov.me](https://bespoyasov.me/blog/clean-architecture-3/?utm_source=chatgpt.com)[Medium](https://medium.com/%40mammimia/clean-architecture-part-iv-architecture-5eee3cb5656a?utm_source=chatgpt.com).
- **Dades Crítiques (Critical Business Data)**
Són les dades necessàries perquè les Regles Crítiques funcionin. Tant les regles com les dades són part del domini de negoci i han de romandre independents dels detalls d’implementació.
- **Entitats (Entities)**
Objectes del sistema que encapsulen tant les Regles Crítiques com les Dades Crítiques. Una entitat ofereix una interfície neta on s’implementa la lògica de negoci i queda aïllada de la base de dades, la UI o altres mecanismes externs [Bookey](https://www.bookey.app/book/clean-architecture?utm_source=chatgpt.com).
- **Casos d’Ús (Use Cases)**
Representen les **Regles de negoci específiques de l’aplicació**; defineixen pas a pas com l’usuari interactua amb el sistema, especificant clarament les entrades, sortides i l’ordre d’execució de la lògica. Els casos d’ús no llegeixen ni escriuen directament a la UI o la BD, sinó que actuen mitjançant models de petició i resposta desacoblats [bespoyasov.me](https://bespoyasov.me/blog/clean-architecture-3/?utm_source=chatgpt.com).
- **Models de Petició i Resposta**
Estructures de dades que porten la informació des de la UI cap als casos d’ús (request models) i retornen el resultat (response models). No contenen cap dependència de framework, de manera que la lògica de negoci roman totalment independent.
- **Conclusió**
Les Business Rules constitueixen el cor de l’aplicació: han d’estar encapsulades dins d’entitats ben definides i exposades a través de casos d’ús explícits. Mantenir-les allunyades dels detalls tècnics (bases de dades, UI, frameworks) assegura que el sistema sigui testable, flexible i perduri davant canvis tecnològics
#### C22: The Clean Architecture
- **Visió Global de l’Arquitectura**
El Capítol 22 sintetitza l’evolució de les arquitectures modernes (Hexagonal, Onion, DCI, BCE) en un model de cercles concèntrics que aïllen la lògica de negoci dels detalls tècnics [Bookey](https://www.bookey.app/book/clean-architecture?utm_source=chatgpt.com).
- **Independència de Frameworks**
Els frameworks són tractats com a “plugins”: eines a la vora de l’arquitectura que poden canviar sense impactar el nucli de regles de negoci [blog.vranec.com](https://blog.vranec.com/2017/10/notes-about-clean-architecture-book.html?utm_source=chatgpt.com).
- **Testabilitat**
En tenir la lògica de negoci completament aïllada (entitats i casos d’ús), es pot provar amb tests de unitat purs sense mocks de bases de dades, UI o altres detalls externs [blog.vranec.com](https://blog.vranec.com/2017/10/notes-about-clean-architecture-book.html?utm_source=chatgpt.com).
- **Independència de la Interfície d’Usuari**
La UI és una capa externa més; pot ser substituïda (web, mòbil, CLI…) sense tocar els cercles interns de l’arquitectura [blog.vranec.com](https://blog.vranec.com/2017/10/notes-about-clean-architecture-book.html?utm_source=chatgpt.com).
- **Independència de la Base de Dades**
El model i la lògica no depenen d’un tipus concret de persistència. Els adaptadors de base de dades queden al límit exterior i depenen de les abstraccions definides pel nucli [blog.vranec.com](https://blog.vranec.com/2017/10/notes-about-clean-architecture-book.html?utm_source=chatgpt.com).
- **Independència d’Agències Externes**
Qualsevol servei extern, APIs de tercers o sistemes de missatgeria es tracten com a plugins externs; el sistema no depèn directament d’ells [blog.vranec.com](https://blog.vranec.com/2017/10/notes-about-clean-architecture-book.html?utm_source=chatgpt.com).
- **Dependency Rule (Regla de Dependències)**
El codi només pot dependre de caps més interns: de fora cap al centre. Això garanteix que les capes externes no contaminin la lògica crítica [Bookey](https://www.bookey.app/book/clean-architecture?utm_source=chatgpt.com).
- **Cercles Concèntrics**
1. **Entities**: regles i dades crítiques del domini.
2. **Use Cases**: orquestren lògica específica d’aplicació.
3. **Interface Adapters**: converteixen dades entre el nucli i el món extern.
4. **Frameworks & Drivers**: detalls d’implementació (web, BD, UI).
Aquesta disposició visual fa evident la separació de responsabilitats i facilita la comprensió de l’arquitectura [Bookey](https://www.bookey.app/book/clean-architecture?utm_source=chatgpt.com).
#### C25: Layers and Boundaries
- **Distinció entre capes i fronteres**
Una **capa** és una agrupació lògica de classes amb responsabilitats similars (per exemple, UI, casos d’ús, entitats), mentre que una **frontera** (**boundary**) és la línia de separació que defineix com circulen les dependències entre capes. Les capes existeixen dins dels límits; la inversió de dependències s’aplica a les fronteres per fer-les efectives .
- **Principi d’Inversió de Dependències a les fronteres**
Les fronteres utilitzen interfícies per invertir les dependències: les classes de la capa exterior depenen d’abstraccions de la capa interior, no pas a l’inrevés. Així, la lògica de negoci queda aïllada de detalls com la UI o la persistència .
- **Acoblament i independència**
Traçar capes ben definides i aplicar la regla de dependències evita l’acoblament fort entre mòduls. Cada capa només coneix la interfície de la capa immediatament interior, facilitant el reemplaçament o evolució de detalls sense fer malbé la lògica central .
- **Organització de paquets**
L’autor recomana estructurar el codi en paquets modulars per cada capa (p. ex., `domain`, `usecase`, `adapter`), reflectint tant la jerarquia de capes com les fronteres i ajudant a que la dependència apunti sempre cap al centre .
- **Benefici de les capes lleugeres**
No cal reproduir totes les capes amb grans jerarquies; un nombre mínim de capes amb fronteres clares i inversió de dependències ja aporta testabilitat, mantenibilitat i flexibilitat per canviar tecnologies externes .
## 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 -->
-