Introdução
Diagramas são uma ótima maneira de comunicar algo visualmente. No entanto, a maioria dos diagramas de arquitetura de software realmente não expressa o que pretendem, carecendo de descrição de seus elementos e com muitas notações implícitas compreendidas apenas por quem desenhou o diagrama. Além disso, eles tentam expressar mais de uma visão (alto nível, infraestrutura, ordem de fluxo, etc) em apenas um diagrama, tornando ainda mais difícil para pessoas não técnicas ou pessoas de fora do projeto entenderem.
Neste post, apresentarei o modelo C4 e como ele pode produzir diagramas de arquitetura de software que são inclusivos para pessoas não técnicas, mais fáceis de entender e, consequentemente, melhores para documentar nossos sistemas de software.
O modelo C4
O modelo C4 é uma abordagem diferente para projetar diagramas de arquitetura de software. Ele tem um conceito de quatro níveis hierárquicos principais de diagramas e prioriza abstrações sobre notação. O que isso significa é que tipos comuns de elementos são mais importantes do que tipos de caixas e tipos de setas com significados implícitos. As notações causam confusão e limitam as pessoas que podem ler os diagramas àquelas que conhecem a notação ou o projeto.
As abstrações existem para ajudar aqueles que desenham os diagramas, em contraste com as notações que precisam ser conhecidas por todos que leem os diagramas. A ideia é que os diagramas devem ser entendidos por si mesmos, sem qualquer conhecimento prévio do projeto ou da notação. Deve auxiliar a comunicação dentro e fora da equipe.
Ele também tem uma definição clara do escopo de cada diagrama, com diagramas complementares, por exemplo, para mostrar a sequência de eventos ou a infraestrutura onde o sistema é implantado.
Diagramas principais
Os níveis de diagramas funcionam como um mapa, onde ampliamos do país para a cidade para ver mais detalhes.
Na imagem abaixo, ampliamos o sistema para ver seus containers, ampliamos um container para ver seus componentes e ampliamos um componente para ver seu código.
Contexto do sistema
O diagrama de primeiro nível fornece um contexto de como o sistema interage com os usuários e outros sistemas externos. Detalhes sobre tecnologia não devem estar neste nível e devem ser entendidos por pessoas não técnicas.
Aqui podemos ver o que está no escopo do nosso sistema e o que não está. Além disso, vemos as interações do nosso sistema com usuários e sistemas externos.
Elementos neste diagrama:
- O sistema em escopo;
- Usuários/pessoas e suas interações com o sistema;
- Sistemas externos e suas interações com o sistema.
Containers
O diagrama de containers mostra os containers dentro do limite do sistema. Os containers no modelo C4 não têm relação com o docker e outros tempos de execução de containers; eles são apenas um nome para uma parte do sistema. Os containers são quase sempre aplicativos implantáveis separadamente que compõem um sistema e que se comunicam entre si por meio de comunicação entre processos ou via rede. Exemplos de containers são: aplicativos de página única, aplicativos de desktop, APIs, bancos de dados, filas, tópicos de eventos e caminhos de armazenamento.
Neste nível, devemos começar a descrever a tecnologia usada nos containers e nas interações. Por exemplo, “Aplicativo móvel - [Container: Xamarin/C#]”, “Faz chamadas de API para [JSON/HTTPs]”.
Ele ainda mostra os usuários e sistemas externos, mas neste nível, mostra as interações com cada container. No diagrama abaixo, o usuário interage com o Aplicativo de página única e não com o Limite do sistema bancário pela Internet.
Elementos neste diagrama:
- O limite do sistema;
- Usuários/pessoas e suas interações com os containers;
- Sistemas externos e suas interações com os containers.
Componentes
O diagrama de componentes mostra um container dividido em componentes e suas interações entre si e outros containers ou sistemas externos. Os componentes são unidades importantes de código; eles podem ser elementos de interface em aplicativos frontend, controladores em APIs ou páginas em aplicativos web.
Este nível é recomendado apenas quando julgado útil porque quanto mais ampliamos, mais difícil é mantê-lo atualizado.
Elementos neste diagrama:
- O limite do container;
- Outros containers e suas interações com os componentes do container em escopo;
- Sistemas externos e suas interações com os componentes.
Código
No diagrama de código, podemos dar detalhes dos componentes com diagramas de classe UML ou outros diagramas semelhantes.
Este nível não é recomendado porque é muito difícil de manter atualizado, a menos que seja gerado automaticamente a partir do código-fonte. Mesmo assim, deve ser usado apenas quando estritamente necessário.
Elementos neste diagrama:
- O limite do componente;
- Classes e interfaces dentro do componente.
Diagramas suplementares
C4 tem mais diagramas que podem ser usados quando necessário:
Diagrama de paisagem do sistema
Um nível acima do diagrama de contexto do sistema. Útil se mostrar mais de um sistema for necessário.
Diagrama dinâmico
Semelhante ao diagrama de sequência UML. Mostra a ordem das interações entre os elementos.
Pessoalmente, acho o Diagrama de sequência UML mais fácil de entender, mesmo para pessoas não técnicas, porque eles têm uma ordem de cima para baixo e da esquerda para a direita, então normalmente o uso em vez do diagrama dinâmico C4.
Diagrama de implantação
Descreve a infraestrutura e como os containers do sistema são implantados nela.
Aqui estão mais detalhes sobre esses diagramas.
Algumas notas importantes
- Os diagramas devem ter título e seu tipo no cabeçalho;
- Acrônimos devem ser evitados para tornar os diagramas inclusivos para todos;
- Os elementos devem ter seu tipo e a descrição de suas responsabilidades;
- As interações entre os elementos devem ter uma e apenas uma direção (sem linhas com zero ou duas direções) e ser descritivas. Exemplo: “envia e-mails usando” em vez de “usa”;
- As interações não precisam de uma linha de resposta. Duas linhas podem ser usadas apenas se a interação puder começar de ambos os elementos;
- A direção da interação não importa, desde que a descrição corresponda a ela;
- Tipos de caixas e cores devem ser complementares e não necessários para entender o diagrama.
Lista de verificação de revisão do diagrama
Existe uma ferramenta de lista de verificação que podemos usar para revisar nossos diagramas aqui.
Diagrama como código
É altamente recomendável criar diagramas C4 como código. Isso os torna mais fáceis de alterar e manter atualizados. Falei sobre diagramas como código neste post.