Come la legge di Conway e le topologie organizzative modellano i microservizi?

Question

IT Interview Practice · Accepted Answer

I microservizi sono tanto una decisione **organizzativa** quanto una tecnica. La **legge di Conway** afferma che i sistemi rispecchiano la struttura di comunicazione dell'organizzazione che li costruisce — quindi la struttura del tuo team modella la tua architettura, lo voglia o meno.

## Perché è importante

```text
"Organizations design systems that copy their communication structure."

3 teams that don't talk  →  3 services with awkward, accidental seams
→ Inverse Conway Maneuver: design TEAMS around the architecture you want
```

## Proprietà del team

Ogni servizio dovrebbe avere un **chiaro team proprietario** che lo costruisce, distribuisce e gestisce ("tu lo costruisci, tu lo gestisci"). La proprietà condivisa porta a servizi trascurati.

```text
Orders team   ─owns─▶ Orders service (code + deploy + on-call)
Payments team ─owns─▶ Payments service
→ autonomy: each team ships without waiting on others
```

## Team Topologies

| Tipo di team | Ruolo |
|---|---|
| Stream-aligned | Possiede una parte del prodotto (la maggior parte dei team) |
| Platform | Fornisce infrastruttura self-service (CI/CD, mesh) |
| Enabling | Allena altri team su pratiche |
| Complicated-subsystem | Possiede un'area specializzata profonda |

L'obiettivo è minimizzare il **carico cognitivo** cross-team e i passaggi di consegna.

## Trappola

Adottare microservizi senza ristrutturare i team produce un monolite distribuito, perché i vecchi pattern di coordinamento si infiltrano nell'architettura.

## Perché è importante

Se i team devono coordinare costantemente per rilasciare una funzionalità, l'architettura rifletterà quel coupling indipendentemente da come traccia chiaramente i diagrammi dei servizi.

Allineare i confini del team con i confini del servizio (la manovra di Conway inversa) è quello che effettivamente fornisce l'autonomia e i vantaggi di distribuzione indipendente che i microservizi promettono — l'organigramma è parte del design.

Tipo di team	Ruolo
Stream-aligned	Possiede una parte del prodotto (la maggior parte dei team)
Platform	Fornisce infrastruttura self-service (CI/CD, mesh)
Enabling	Allena altri team su pratiche
Complicated-subsystem	Possiede un'area specializzata profonda

Perché è importante

Proprietà del team

Team Topologies

Trappola

Perché è importante

Domande correlate