L'arquitectura d'aplicacions és la disciplina que defineix l'estructura fonamental d'un sistema de programari: com s'organitzen les seves peces, com es comuniquen entre elles i quines decisions de disseny són tan importants que resulta costós canviar-les més endavant. Per a un professional del desenvolupament, comprendre l'arquitectura no és un luxe acadèmic, sinó la diferència entre construir un sistema que evoluciona amb elegància durant anys i un que es torna fràgil, lent de modificar i car de mantenir. En aquesta lliçó posem les bases conceptuals: què és realment l'arquitectura, com es distingeix de termes propers que sovint es confonen, en quins nivells d'abstracció opera i quina mena de decisions abasta.

1. Definició d'arquitectura d'aplicacions
2. Arquitectura de programari, d'aplicacions i empresarial: diferències
3. Nivells d'abstracció
4. Quines decisions abasta l'arquitectura
5. Per què és important l'arquitectura
6. Un exemple concret

Existeixen moltes definicions, però gairebé totes comparteixen una idea central. Una de les més citades, de la norma ISO/IEC/IEEE 42010, diu que l'arquitectura són els conceptes o propietats fonamentals d'un sistema en el seu entorn, materialitzats en els seus elements, les seves relacions i els principis del seu disseny i evolució.

En termes més pràctics, ens podem quedar amb la definició de Martin Fowler:

"L'arquitectura són les decisions importants, on important es mesura pel cost de canviar-les."

D'aquí n'extraiem les característiques clau:

• És estructural: descriu els elements del sistema (mòduls, serveis, capes) i com es relacionen.
• És sobre allò difícil de canviar: se centra en les decisions d'alt impacte, no en cada detall d'implementació.
• Té en compte l'entorn: el context de negoci, els usuaris, les restriccions legals o d'infraestructura.
• Guia l'evolució: estableix principis perquè el sistema creixi de manera coherent.

Convé distingir dues accepcions del terme:

Aquests tres termes s'usen sovint de manera intercanviable, però operen en àmbits diferents. Entendre la frontera entre ells evita confusions en reunions i documents.

Una manera de visualitzar-ho és com a cercles concèntrics:

Aquest diagrama Mermaid usa graph TD (un graf dirigit de dalt a baix, top-down). Cada node es defineix amb un identificador (EA, AA, SA) i una etiqueta entre claudàtors. Les fletxes --> indiquen que l'arquitectura empresarial "conté" o "engloba" la d'aplicacions, i aquesta al seu torn la de programari. La idea no és jerarquia de comandament, sinó d'abast: com més enfora, més ampli és l'àmbit i més proper al negoci.

L'arquitectura es pensa en diferents nivells de detall. Treballar en el nivell equivocat és un error freqüent: discutir noms de variables en una reunió d'arquitectura, o intentar dissenyar tot el sistema sense baixar mai a verificar que les idees són implementables.

• Nivell de sistema (alt): límits del sistema, actors externs, sistemes amb què s'integra. Es pensa en caixes grans.
• Nivell de contenidor: unitats desplegables com ara una aplicació web, una API, una base de dades o un broker de missatgeria.
• Nivell de component: agrupacions lògiques dins d'un contenidor (per exemple, un mòdul de facturació, un servei d'autenticació).
• Nivell de codi (baix): classes, funcions i interfícies concretes.

Veurem aquests nivells amb detall en la lliçó sobre el model C4. De moment, retén la idea que l'arquitecte puja i baixa constantment entre nivells, assegurant-se que les decisions d'alt nivell són realitzables en el codi i que el codi respecta la visió global.

No totes les decisions d'un projecte són arquitectòniques. Allò arquitectònic és el que té un impacte ampli, és difícil de revertir o afecta atributs de qualitat clau. Algunes categories típiques:

• Estil i patrons: monòlit, microserveis, arquitectura per capes, hexagonal, dirigida per esdeveniments?
• Tecnologies estructurals: llenguatge principal, motor de base de dades (relacional vs documental), plataforma de desplegament (contenidors, serverless).
• Integració i comunicació: comunicació síncrona (REST, gRPC) o asíncrona (cues, esdeveniments)?
• Gestió de dades: on viu cada dada, què és la font de veritat, com es garanteix la consistència.
• Atributs de qualitat: com s'aconsegueixen rendiment, escalabilitat, seguretat o disponibilitat.
• Transversals (cross-cutting): autenticació, registre de logs, monitoratge, gestió d'errors.

Compara una decisió arquitectònica amb una decisió d'implementació:

Una bona arquitectura no es nota quan està ben feta; una de dolenta es nota cada dia. Els seus beneficis principals:

• Facilita el canvi: un sistema ben estructurat permet afegir funcionalitats sense reescriure mig sistema.
• Gestiona la complexitat: divideix un problema gran en peces comprensibles i delimitades.
• Habilita els atributs de qualitat: el rendiment o la seguretat no s'"afegeixen al final", es dissenyen des del principi.
• S'alinea amb el negoci: tradueix objectius de negoci (créixer, complir la normativa, reduir costos) en estructura tècnica.
• Redueix el risc: les decisions difícils es prenen conscientment, no per accident.

El concepte de deute tècnic ajuda a entendre-ho: cada drecera arquitectònica que prenem avui és un "préstec" que pagarem amb interessos (més lentitud de desenvolupament) demà. L'arquitectura conscient decideix quan val la pena demanar aquest préstec i quan no.

Imagina una botiga en línia. Una decisió arquitectònica seria separar el processament de pagaments en un servei independent que es comunica de manera asíncrona:

Aquest YAML descriu tres serveis desplegables (contenidors). La clau arquitectònica és a cua-esdeveniments: en lloc que botiga-web cridi directament servei-pagaments (acoblament fort i síncron), tots dos depenen d'una cua de missatgeria. Així, si el servei de pagaments està temporalment caigut, les comandes s'encuen i es processen més tard, millorant la disponibilitat. Aquesta és una decisió arquitectònica: afecta diversos components, és costosa de revertir i persegueix un atribut de qualitat concret.

• Confondre arquitectura amb tecnologia. Escollir "Spring Boot i Kafka" no és tenir arquitectura. L'arquitectura són les decisions estructurals i els seus motius, no la llista d'eines.
• Sobredissenyar (over-engineering). Dissenyar per a una escala que mai arribarà introdueix complexitat innecessària. Aplica el principi YAGNI (You Aren't Gonna Need It) i dissenya per al que saps i per al que és raonablement previsible.
• No dissenyar res (under-engineering). L'extrem oposat: deixar que l'estructura "emergeixi" sense cap intenció produeix el temut "gran cabdell de fang" (big ball of mud).
• Oblidar el context de negoci. La millor arquitectura tècnica és inútil si no serveix els objectius de l'organització.
• Consell: documenta el perquè. El més valuós d'una decisió no és què vas decidir, sinó per què. Ho veurem amb els ADR en lliçons posteriors.

Exercici 1. Classifica les decisions següents com a arquitectòniques o d'implementació: (a) usar PostgreSQL com a base de dades principal; (b) reanomenar un mètode calc() a calcularTotal(); (c) dividir el sistema en frontend i backend separats; (d) afegir un índex a una columna molt consultada.

Exercici 2. Explica amb les teves paraules la diferència entre arquitectura de programari, d'aplicacions i empresarial, usant un exemple d'un banc.

Exercici 3. Per a la botiga en línia de l'apartat 6, proposa una decisió arquitectònica addicional orientada a millorar la seguretat i justifica per què és arquitectònica.

Solució 1. (a) Arquitectònica: el motor de base de dades afecta tot el sistema i és costós de canviar. (b) Implementació: canvi local i trivial. (c) Arquitectònica: defineix l'estructura de desplegament i la comunicació. (d) Generalment d'implementació/optimització, llevat que el patró d'accés a dades canviï de manera estructural; té un impacte local i és reversible.

Solució 2. En un banc: l'arquitectura de programari descriu com està construït per dins el sistema de transferències (les seves capes, classes, patrons). L'arquitectura d'aplicacions descriu quines aplicacions existeixen (banca en línia, app mòbil, core bancari, sistema antifrau) i com s'integren entre elles. L'arquitectura empresarial alinea tota la tecnologia del banc amb la seva estratègia: capacitats de negoci (captar clients, concedir préstecs), compliment normatiu i roadmap tecnològic.

Solució 3. Exemple: introduir una passarel·la d'API (API Gateway) que centralitzi l'autenticació i autorització de totes les peticions externes. És arquitectònica perquè defineix un nou component estructural per on passa tot el trànsit, afecta múltiples serveis, persegueix l'atribut de qualitat seguretat i revertir-la implicaria redistribuir la lògica de seguretat per tots els serveis.

Hem definit l'arquitectura d'aplicacions com el conjunt de decisions estructurals difícils de canviar, l'hem diferenciada de l'arquitectura de programari i l'empresarial, hem recorregut els seus nivells d'abstracció, identificat quines decisions abasta i argumentat per què importa. La idea central que t'has d'endur és que l'arquitectura existeix sempre, decideixis conscientment o no; l'objectiu d'aquest curs és que la decideixis amb intenció. En la lliçó següent estudiarem qui pren aquestes decisions: el rol de l'arquitecte de programari, les seves responsabilitats, tipus i les habilitats que necessita.