L'architettura dei team (struttura organizzativa) influisce direttamente sull'architettura dei sistemi IT aziendali. Questo è legato alla "legge di Conway": un sistema sviluppato da un'organizzazione riflette le strutture di comunicazione dei team.
Se si progetta un sistema tenendo conto dei team cross-functional, si ha la possibilità di distribuire la responsabilità sui domini, ridurre i punti di intersezione e diminuire le dipendenze architettoniche.
Esempio di formazione delle aree di responsabilità e dei confini architettonici:
In ciascun dominio risponde un team specifico, i contratti API sono massimamente formalizzati, l'interazione avviene tramite interfacce pubbliche o basate su eventi. Questo semplifica la scalabilità dello sviluppo e accelera la reattività ai cambiamenti.
Caratteristiche chiave:
Domanda: È possibile assegnare a un solo team la manutenzione di più grandi domini?
Nei grandi sistemi — no, ciò comporta sovraccarico e colli di bottiglia nella comunicazione. È meglio formare team secondo il principio "un dominio — un team".
Domanda: I confini dei microservizi devono sempre coincidere con i confini dei team?
Ideale — sì, ma nella pratica non è sempre possibile. Tuttavia, è necessario puntare a questo per ottimizzare le comunicazioni e ridurre il numero di integrazioni tra servizi.
Domanda: È importante coordinare le decisioni architettoniche tra i team, se sono completamente indipendenti?
Sì, è criticamente importante! Per prevenire uno "zoo tecnologico" e mantenere gli standard di integrazione, è necessario un coordinamento architettonico, ad esempio, comitati architettonici o guild.