O modelo C4, em quatro níveis
O C4 é uma forma de desenhar arquitetura de software criada por Simon Brown. A ideia central é a de um mapa com níveis de zoom: em vez de um desenho único que tenta caber tudo, você tem quatro desenhos, cada um respondendo a uma pergunta diferente, para um público diferente.
Esta página ensina só o que é preciso para usar o cfourdev. Se você quiser a fonte original, ela está em c4model.com.
Os quatro níveis
Seção intitulada “Os quatro níveis”| Nível | Pergunta que ele responde | Quem costuma ler |
|---|---|---|
| Contexto | Que sistema é este, quem o usa e com que outros sistemas ele conversa? | qualquer pessoa, inclusive quem não é técnica |
| Container | De que partes executáveis este sistema é feito? | quem desenvolve e quem opera |
| Componente | Que peças existem dentro de uma dessas partes? | quem desenvolve aquela parte |
| Código | Como uma peça está estruturada por dentro? | quem vai mexer naquele arquivo |
A palavra container aqui não significa Docker. No C4, um container é qualquer coisa que executa ou guarda dados separadamente: uma aplicação web, uma API, um banco de dados, uma fila, um processo agendado, um aplicativo de celular.
As peças de um diagrama
Seção intitulada “As peças de um diagrama”Pessoa — um ser humano que usa o sistema, ou um papel: cliente, atendente, administrador.
Sistema — um todo que entrega valor. Alguns são seus e você vai detalhar por dentro; outros são de terceiros ou de outra equipe, e você só precisa saber que eles existem e que você conversa com eles.
Container — uma parte executável ou de armazenamento de um sistema seu.
Componente — um agrupamento de código com uma responsabilidade clara dentro de um container.
Relação — uma seta entre duas dessas peças, com um rótulo curto dizendo o que trafega: “consulta o saldo”, “publica o pedido”, “envia o e-mail”. A seta descreve intenção, não protocolo.
Fronteira — a moldura que diz “tudo aqui dentro pertence a esta caixa”. Num diagrama de containers, a fronteira é o sistema que você abriu.
Como o cfourdev representa isso
Seção intitulada “Como o cfourdev representa isso”Esta é a parte que muda a forma de escrever, e vale ler com atenção:
Você não escolhe o nível de uma caixa. Ele é derivado.
No cfourdev, toda caixa pode declarar um parent — a caixa que a contém. Essa
única relação de contenção constrói uma árvore, e a profundidade na árvore é o
nível C4:
sem parent → nível context (um sistema, ou uma pessoa)filho de uma raiz → nível containerfilho de um container → nível componentfilho de um component → nível codeNão existe um quinto nível, e não existe um campo para “eu quero que esta caixa
seja um componente”. Para descer um nível, dê um parent à caixa nova.
Um diagrama não é um nível: é um recorte. O nível de um diagrama vem do que ele mostra. Você pode escrever um diagrama que mistura níveis se isso ajudar quem lê — o modelo não impede.
A aparência é separada do nível. O campo shape de uma caixa escolhe o
desenho: cilindro para banco de dados, silhueta de pessoa para um ator, moldura
tracejada para um sistema de fora. Um cilindro no nível de container e um
cilindro no nível de componente continuam sendo cilindros; o nível decide a cor,
a forma decide o desenho.
“Dynamic” e “Deployment” não existem como níveis aqui. O C4 original tem duas visões complementares além das quatro. O cfourdev implementa a primeira com outro nome e outra forma — os fluxos, que contam um caso de uso como uma sequência de mensagens sobre as caixas que já existem. Não há visão de implantação.
Um exemplo, em palavras
Seção intitulada “Um exemplo, em palavras”Um sistema de reserva de salas:
- contexto: o Colaborador usa a Reserva de Salas, que cria eventos na Agenda Corporativa (um sistema de terceiro);
- container: dentro da Reserva de Salas existem um Painel no navegador, uma API, uma Base de Reservas, uma Fila e um Sincronizador;
- componente: dentro da API existem um Serviço de Reserva, um Repositório de Reservas e um Publicador.
É exatamente esse modelo que as páginas de Modelando constroem, um passo de cada vez.