Diagramas Arquiteturais com C4 — Conceitos principais

Imagine que você assumiu um sistema antigo, que ninguém mais na empresa conhece, e precisa alterar uma certa funcionalidade. O sistema é composto por vários componentes distintos e dezenas de milhares de linhas de código. Você procura por alguma documentação que possa dar uma luz de onde começar a olhar, mas não encontra nada.

Ou talvez você até encontre algo, mas é aquele desenho que mostra apenas um serviço chamando o outro, sem nenhuma contextualização do porquê, sem nenhum detalhe de tecnologias ou motivação.

Desenho arquitetural sem detalhes ou contexto de um sistema hipotético, mostra apenas relações entre serviços

Esse desenho é melhor que nada (desde de que esteja atualizado!). No entanto, ele é deficiente, pois não responde uma série de perguntas que você possa ter, como por exemplo:

• Quais as tecnologias usadas por cada sistema representado no diagrama?
• Por que o sistema chamado gateway possui um banco de dados? O que é armazenado lá?
• Quem utiliza esse sistema?

O desenho acima não pode ser entendido sem uma explicação a mais, ou alguém junto contigo te contextualizando. E como vamos ver ao longo desse artigo, um bom diagrama pode ser entendido praticamente sozinho!

Então, agora imagine que ao invés daquele desenho você tivesse encontrado um desenho muito mais completo, com mais contexto e detalhes, como o seguinte:

Desenho arquitetural feito no modelo C4, mostrando detalhes, tecnologias e relações.

Assim fica muito mais fácil entender o que cada parte faz, certo? O desenho contém, além das relações entre sistemas, detalhes sobre o porquê de certas coisas serem como são. Por exemplo, agora você sabe que aquele banco de dados do gateway foi usado por questões de auditoria! Também é possível rapidamente verificar qual tecnologia foi usada e o que cada sistema faz.

É isso que o modelo C4 se propõe! Criado por Simon Brown, é um conjunto de abstrações e diagramas hierárquicos que são fáceis de aprender e usar, sendo uma ótima forma para visualizar a arquitetura do seu software.

É importante destacar que o exemplo acima é um caso hipotético bastante simples. Mas, em empresas maiores, você vai se deparar com arquiteturas que possuem dezenas, centenas ou até milhares de sistemas! Assim, as vantagens que o C4 trazem são maiores ainda.

Benefícios

Utilizar o modelo C4 e ter seus sistemas mapeados em diagramas traz uma série de benefícios, como:

• Fácil de aprender e utilizar (é um modelo leve, pouco burocrático)
• Após feito, os principais diagramas são pouco voláteis (fáceis de serem mantidos)
• Facilita onboarding de novas pessoas
• Reduz silos de conhecimento, propagando e documentando informações importantes sobre funcionamento de sistemas
• Promove uma visão big picture dos sistemas da empresa
• Facilita revisões de arquitetura e design de solução
• Ajuda a se situar em momentos de crise e para fazer análise de risco
• Serve como o primeiro passo para identificar melhorias (como você quer melhorar aquilo que nem sabe direito como está hoje?)

Abstrações

Antes de entendermos os diagramas que o modelo C4 propõe, é importante entender que quatro abstrações são utilizadas:

• Person (pessoa): representa os usuários que utilizam seu sistema. No nosso exemplo hipotético, o Gerente de Loja.
• Software system (sistema): algo que entrega valor para seus usuários. Normalmente cada empresa utiliza um nome diferente para essa abstração, como aplicação, produto ou serviço.
• Container: é algo que precisa estar rodando para o sistema funcionar, como um serviço ou um banco de dados. Pode ser um servidor Ruby on Rails ou Node.js, uma aplicação web como Angular, um aplicativo mobile, um microsserviço etc.
• Component (componente de código): agrupamento de funcionalidades de código. Se relaciona com os modular monoliths, outro conceito que o Simon Brown aborda.

A forma mais fácil de entender é observando a relação entre esses conceitos:

• um agrupamento de trechos de código formam um component
• um ou mais components formam um container
• um ou mais containers foram um software system
• um software system é utilizado por um usuário (person)

Relações hierárquicas entre os tipos de abstração utilizados no C4

Principais Diagramas

Entendendo as abstrações, podemos finalmente falar dos diagramas!

O modelo dispõe de várias opções, para diferentes necessidades. É importante entender que existem quatro “níveis de zoom”, por isso o nome C4. Quanto mais alto o nível de zoom, mais detalhes de implementação são visíveis.

• Nível 1: Contexto
• Nível 2: Containers
• Nível 3: Componentes
• Nível 4: Código

Consequentemente, temos os diagramas:

1) System Context Diagram

Mostra a big picture. O software system está centralizado e suas relações com usuários e outros software systems é mostrada.

Como é bem alto nível, pode ser mostrado para pessoas não técnicas e é recomendado para a maioria dos times.

Exemplo de System Context Diagram

2) Container Diagram

Dando um zoom em um software system em particular, vemos todos os containers que o compõe, como banco de dados, sistemas web, microsserviços etc.

Nesse nível é possível ver as tecnologias que compõe a arquitetura, bem como a relação desses containers entre si. Esse diagrama também é recomendado para a maioria dos times.

Exemplo de Container Diagram

3) Component Diagram

Dando um zoom novamente, dessa vez em um container específico, temos o diagrama de component. Nele, observamos como os components (grandes blocos de código que entregam uma funcionalidade) se relacionam entre si.

Esse nível de detalhe não deve ser feito pela a maioria dos times, sendo recomendado apenas quando você sentir que realmente traz valor.

Exemplo de Component Diagram

4) Code Diagram

Se você dar zoom em um componente específico, você chega no código. Para isso, basta usar um diagrama de classe UML ou um diagrama entidade relacionamento.

Idealmente isso deve ser gerado automaticamente pela sua IDE.

Outros diagramas

Além dos quatro diagramas principais mencionados, existem mais três complementares:

• System Landscape diagram

Ao invés de focar em apenas um software system, mostra um conjunto de software systems e suas relações.

• Dynamic diagram

Mostra uma sequência passo-a-passo, muito útil para mostrar como uma feature ou caso de uso acontece no sistema.

Uma dos maiores dúvidas que vejo quando as pessoas começam a utilizar o C4 é justamente querer colocar sequências passo-a-passo nos diagramas como System Context ou Containers. Esses diagramas mostram componentes e suas dependências/relações, não uma ordem de operações! Para mostrar essa ordem de operações, utilize o dynamic.

Um ponto de atenção é que esse diagrama é bastante volátil, pois contém muitos detalhes. Logo, utilize apenas nos locais em que ele agrega valor, como fluxos principais ou mais críticos.

• Deployment diagram

Mostra como as instâncias de software systems e containers existem nos ambientes de infra (como staging, produção etc).

Mais detalhes desses diagramas, incluindo exemplos, podem ser acessados no site oficial do Modelo C4.

Quais diagramas utilizar?

Considerando o valor e volatilidade dos diagramas, a tabela abaixo é uma recomendação de quais diagramas utilizar, baseada na minha experiência aplicando o C4.

Tabela de recomendação de quais diagramas utilizar

Para quem está começando, a recomendação é aplicar os níveis C1 e C2. Eles já dão uma boa visão dos sistemas, e como a volatilidade é baixa, é fácil de manter!

Boas práticas

• Cada diagrama deve ser entendido sem precisar de explicação​
• Cada elemento deve ter uma breve descrição de responsabilidades chave​
• A tecnologia utilizada deve estar explícita em cada container​
• Relacionamentos são sempre unilaterais, com descrição consistente
• O Simon Brown disponibiliza um checklist de boas práticas para verificar se o seu diagrama está de acordo com o proposto pelo modelo

Ferramentas

O modelo C4 é independente de ferramenta, ou seja, você pode utilizar a melhor ferramenta que atenda as suas necessidades.

Dito isso, existem várias ferramentas bastante robustas. Há de se pensar se você quer utilizar um modelo visual (“arrastar caixinhas”) ou se quer ir para um modelo mais doc as code (escrever código que gera os diagramas).

Como esse assunto rende, me aprofundarei em um outro artigo, no qual darei um overview de ferramentas e entrarei em mais detalhes sobre uma específica, o Structurizr!

Material complementar e referências

• Site oficial do C4 Model
• Visualising software architecture with the C4 model — Simon Brown, Agile on the Beach 2019
• Diagrams as Code 2.0 • Simon Brown • GOTO 2021
• Site oficial do Structurizr

#engenharia-de-software