Este documento apresenta uma visão geral do C4 Model, uma metodologia proposta por Simon Brown para documentar a arquitetura de software de forma eficiente e clara, utilizando quatro níveis de diagramas. Os diagramas do C4 Model facilitam a comunicação entre as diferentes partes interessadas, ajudando a alinhar entendimentos e a identificar riscos. O texto também discute considerações práticas para a criação de diagramas, ferramentas recomendadas, e a importância de uma documentação clara no desenvolvimento de software.

1. Documentação de
Arquitetura de
Software
Aplicando C4 Model
Douglas Alonso Cruz

2. Douglas Alonso Cruz
Arquiteto de Software / Lider de equipe na Modalgr
Consultor de TI atuando a mais de 20 anos no mercado nacional participando de grandes
projetos para grandes empresas.
Pós Graduado em Engenharia de Software – PUC SP
Graduado em Tecnologia e Desenvolvimento de Sistemas – IBTA SP

3. Diagrama de Sequência
Diagrama de Classes / Colaboração
O que você usa
para diagramas
de arquitetura?
Sendo otimista
1 a cada 10 pessoas usam UML
Diagrama de classes, objetos,
componentes, instalação, pacotes,
estrutura composta, perfil.

4. Definitivamente Engenheiros de Software não são artistas!!!

5. Qual a importância de bons diagramas de software?
Bons diagramas de arquitetura de software auxiliam na comunicação
(tanto dentro quanto fora da equipe de desenvolvimento de software/
produto), integração de nova equipe, equipes de sustentação e
suporte, identificação de riscos e ameaças.
Ajudam a alinhar o entendimento de todos sobre o software que está
sendo construído e tornando as equipes mais eficientes.

6. Mas então, o que é o C4 Model?
Com o uso dos Métodos ágeis a criação de documentação de sistemas
foi sendo deixada de lado e os diagramas complexos da UML também.
Pensando nisso o Arquiteto de Software Simon Brown criou um
combinado de métodos leves, unidos a linguagem gráfica para
representar arquitetura de software tanto para concepção quanto para
documentação;

7. O C4 Model foi criado por Simon Brown entre 2006 e 2011. Elaborado
com conceitos da base do UML e do Modelo arquitetural 4+1
Teve o lançamento oficial do Website e artigo publicado em 2018 e desde então
vem se popularizando.
https://c4model.com/
Simon Brown é consultor independente especializado em arquitetura de software e autor do livro
"Arquitetura de Software para Desenvolvedores" (Software Architecture for Developers).

8. O C4 Model é uma proposta para padronizar de forma coerente e eficiente a
representação da arquitetura de um software.
Os diagramas do C4 Model facilitam a comunicação entre todos os envolvidos no
projeto do software.
A construção dos diagramas conforme prescrito no C4 Model permite que você
consiga ter uma linguagem consistente, em quatro níveis de detalhe, conforme a
necessidade (e o stakeholder).
Para que serve o C4 Model?

9. Ao criar uma documentação precisamos entender que teremos
pessoas com diferentes interesses vendo aquela documentação
(arquiteto de software, desenvolvedores, time de operações,
testers, diretores, PO, gerentes de projeto, scrum masters, usuários,
patrocinadores, clientes, investidores, ...)

10. Mova-se rápido na mesma direção
que o seu time precisa
Boa comunicação é a chave do sucesso

11. Níveis do C4 Model.
O nome C4 vem dos quatro “níveis” de diagrama propostos pelo autor.
Contexto
contêiners
Componentes
Classes/Código

12. Software System
contêiner
Component
Code
C4 Model
Contexto
contêiners
Componentes
Classes/Código
Diagramas principais (Core diagrams)

14. Level 1 – System Context Diagram
O nível 1, um diagrama de contexto do sistema, mostra o sistema de
software que você está construindo e como ele se encaixa no mundo em
termos das pessoas que o utilizam e dos outros sistemas de software com
os quais ele interage.
• Escopo: O sistema de software em escopo;
• Elementos primários: Pessoas (users, personas, actors, etc), Sistemas
de software (dependências externas) que se conectam diretamente ao
sistema em escopo.
• Público alvo: Pessoas técnicas e não técnicas, dentro e fora da equipe
de desenvolvimento de Software.

16. Level 2 – contêiner Diagram
O nível 2, um diagrama de contêiner, amplia o sistema de software e
mostra os contêiners (aplicativos, armazenamentos de dados,
microservices, etc.) que compõem esse sistema de software. As decisões de
tecnologia também são uma parte fundamental desse diagrama.
• Escopo: um único sistema de software;
• Elementos primários: Pessoas e Sistemas de software (dependências
externas) que se conectam diretamente ao contêiner.
• Público alvo: Pessoas técnicas, dentro e fora da equipe de
desenvolvimento de Software, incluindo arquitetos, desenvolvedores e
time de operações e suporte.

18. Level 3 – Component Diagram
O nível 3, um diagrama de componentes, amplia um contêiner individual
para mostrar os componentes dentro dele. Esses componentes devem
mapear para abstrações reais (por exemplo, um agrupamento de código)
em sua base de código.
• Escopo: um único contêiner;
• Elementos primários: Componentes do contêiner em escopo;
• Público alvo: arquitetos e desenvolvedores.

19. contêiner que será
expandido no
diagrama de
componente

21. Level 4 – Class and Code
O nível 4, finalmente se você realmente quiser ou precisar, você pode
ampliar um componente individual para mostrar como esse componente é
implementado.
Especificamente o diagrama de nível 4, Simon Brown não encoraja o
arquiteto a criar este diagrama, uma vez que as IDEs modernas conseguem
gerar de forma automática de acordo com as classes do seu sistema.
• Escopo: um único componente;
• Elementos primários: Elementos de código (classes, interfaces,
objetos, funções, tabelas de banco de dados, etc) ligados ao
componente em escopo;
• Público alvo: arquitetos e desenvolvedores.

23. Considerações Importantes - Notações
A notação: o modelo c4 não prescreve nenhuma notação específica, e
o que você vê nesses diagramas apresentados é uma notação simples
que funciona bem em quadro brancos, papéis, notas adesivas e uma
variedade de ferramentas de diagramação.
É altamente recomendado que cada elemento inclua um nome, o tipo de elemento, uma
opção de tecnologia (se apropriado) e algum texto descritivo.
Pode parecer incomum incluir tanto texto em um diagrama, mas esse texto adicional elimina
Grande parte da ambiguidade vista em diagramas de arquitetura de software.

24. Considerações Importantes - Notações
Certifique-se de que você tenha uma chave/legenda para descrever qualquer notação que
esteja usando, mesmo que seja óbvio para você.
Chave legenda utilizada nos exemplos
E finalmente, não se esqueça do título do diagrama que deve aparecer em cada diagrama para descrever
Inequivocamente o tipo e o escopo de cada diagrama. Exemplo “Context Diagram of E-mail System”

25. Considerações Importantes - Notações
Diagramas Elementos Relacionamentos
Cada diagrama deve ter um título que
descreve o tipo e o escopo do diagrama
(por exemplo, "Diagrama de contexto
do sistema para Meu sistema de
software").
O tipo de cada elemento deve ser
especificado explicitamente (por
exemplo, Pessoa, Sistema de Software,
contêiner ou Componente).
Cada linha deve representar uma
relação unidirecional.
Cada diagrama deve ter uma chave /
legenda explicando a notação que está
sendo usada (por exemplo, formas,
cores, estilos de borda, tipos de linha,
pontas de seta, etc).
Cada elemento deve ter uma breve
descrição, para fornecer uma visão
"rápida" das principais
responsabilidades.
Cada linha deve ser rotulada, sendo a
etiqueta consistente com a direção e
intenção do relacionamento (por
exemplo, dependência ou fluxo de
dados).
Siglas e abreviações (negócios /
domínio ou tecnologia) devem ser
compreensíveis por todos os públicos
ou explicados na chave / legenda do
diagrama.
Cada contêiner e componente deve ter
uma tecnologia explicitamente
especificada.
Os relacionamentos entre os
contêineres (geralmente representam a
comunicação entre processos) devem
ter uma tecnologia / protocolo
explicitamente rotulado.

26. Diagramas Complementares
Até aqui foi demonstrado diagramas de um sistema simples, mas esse não é
o dia a dia das grandes corporações, o cenário é bem diferente, são muitos
sistemas, banco de dados, filas se comunicando dentro e fora das fronteiras
da empresa, como apresentar isso?

27. 1) System Landscape diagram
Fica “No Topo” do C4, para mostrar o panorama do sistema de uma
perspectiva de TI, facilitando o entendimento das fronteiras do sistema
dentro da empresa.
É um mapa de alto nível dos sistemas de software a nível corporativo, com
um detalhamento C4 para cada sistema de interesse.
É um diagrama de contexto do sistema, sem foco especifico em um sistema
de software específico.
• Escopo: Uma empresa;
• Elementos primários: Pessoas e sistemas de software relacionados à
empresa em escopo;
• Público alvo: Pessoas técnicas e não técnicas, dentro e fora da equipe de
desenvolvimento de Software.

29. 1) System Landscape diagram
A tendencia é que estes diagramas se tornem grandes, complexos e com muitos
relacionamentos, neste caso o ideal é criar vários diagramas, fatiando o contêiner.

32. 2) Dynamic diagram
O Dynamic diagram pode ser útil para demonstrar como os elementos em
um modelo estático colaboram em tempo de execução para implementar
uma história de usuário, um caso de uso, um recurso etc.
É semelhante ao diagrama de sequência, porem permite um arranjo de
forma livre dos seus elementos com interações numeradas para indicar
ordem.
• Escopo: uma empresa, sistema de software ou contêiner;
• Elementos primários: Depende do escopo do diagrama (Landscape,
Leve 1,2,3);
• Público alvo: Pessoas técnicas e não técnicas, dentro e fora da equipe
de desenvolvimento de Software.

34. 3) Deployment diagram
O diagram de implantação permite ilustrar como os sistemas de software e ou /contêineres
serão implantados na infraestrutura. Mostra o mapeamento entre os contêiners e nós de
implantação.
Um nó de implantação é algo como infraestrutura física (ex servidor, dispositivo físico),
infraestrutura virtualizada (IasS, PaaS, maquina virtual), infraestrutura em contêiner (Docker,
kubernetes), ambiente de execução (database, servidores web, servidor aplicativo). Os nós
podem estar aninhados
• Escopo: Um ou mais sistema de software;
• Elementos primários: Nós de deploy, instancias de sw e contêineres
• Público alvo: Pessoas técnicas, dentro e fora da equipe de
desenvolvimento de Software, incluindo arquitetos de software,
arquitetos de infra, desenvolvedores, time de operação e suporte

36. Ferramentas
Structurizr Archi Visio Sparx EA
MooD PlantUML Diagrams.net OmniGraffle
Algumas ferramentas para construção dos diagramas.
Atenção especial ao Structurizr
que permite criar diagramas
através de código utilizando
uma DSL DSL - Domain Specific Language?
Diagram as Code?
https://structurizr.com/help/code
Fica para uma próxima conversa!!!

37. Referências
https://c4model.com/
https://www.infoq.com/br/articles/C4-architecture-model/
https://www.eximiaco.tech/pt/2019/08/12/o-que-e-e-para-que-serve-o-c4-model/
Ebook - Software Architecture for Developers: Volumes 1 & 2
Open Agile Architecture™, a Standard of The Open Group
Agile Architecture Modeling using the ArchiMate® Language
www.modalgr.com.br

38. OBRIGADO
Douglas Alonso
douglas.alonso@modalgr.com.br
http://www.modalgr.com.br

39. Somos um time apaixonado por tecnologia e a entrega de
resultados é uma obsessão de nossos consultores.
A entrega de Resultados está no nosso DNA. Nosso Time
trabalha para atender os clientes, entregando o melhor
resultado, dentro do prazo e custo esperado.
Venha trabalhar na Modalgr
Temos Vagas
https://youtu.be/mUVzPBrAgqQ