Criando um Modelo C4
Compreendendo rapidamente a arquitetura geral do sistema por meio do diagrama do Modelo C4.
Assumir o papel de Arquiteto de Software não é fácil. As equipes, os gerentes e até mesmo as empresas têm grandes expectativas em relação a um Arquiteto de Software, uma das quais é entender todo o sistema tanto em uma visão geral quanto em nível de implementação detalhada no código.
Fazer a transição de uma visão geral para um nível detalhado é comprovadamente muito cansativo. Quanto mais complexo o sistema dentro da empresa, mais difícil é entender todos os detalhes em sua totalidade. Sinceramente, não tenho certeza se alguém consegue compreender todo o sistema, desde uma visão geral até o nível detalhado (codificação), sem ler a documentação. Se houver alguém assim, eu questionaria se são humanos ou alienígenas.
Uma triste história de um Arquiteto de Software
A captura de tela acima mostra um exemplo do cotidiano de um arquiteto de software. Como você pode ver nos padrões de reuniões, existem dois tipos de padrões gerais.
- Reuniões de alto nível (visão geral), como "Desacoplamento xxx", "Risco xxx", "Event Storming xxx", "Domain Storytelling xxx", "Centralização xxx", etc., que impactam várias equipes e exigem colaboração.
- Reuniões de baixo nível (visão detalhada), como "RFC xxx", "Standup", etc.
Imagine se o arquiteto está participando de uma reunião, por exemplo, "Desacoplamento xxx". Nessa reunião, o arquiteto precisa pensar em uma perspectiva de alto nível. Ou quando ele está participando de uma reunião com a alta administração, por exemplo, "Centralização xxx", ele precisa pensar na direção de longo prazo das equipes, do sistema e do fluxo de negócios que são afetados. E imagine novamente, depois de uma longa sequência de reuniões com tópicos de alto nível, de repente ele precisa participar de uma reunião de baixo nível (detalhada), como a implementação de uma RFC.
Este é um exemplo de uma conversa.
Eric: Olá? Sim, em que posso ajudar você?
João: Não consigo fazer o pull da biblioteca privada do Go, como faço isso?
Eric: Ah, você pode ler isso e certifique-se de estar conectado à nossa VPN.
João: Em qual repositório devo implementar isso? E qual executor de fila devo usar? Qual cronograma? etc..
Você consegue imaginar se fosse ele? Quando você já está exausto com todas as reuniões em alto nível e, de repente, precisa mudar o foco para detalhes muito específicos de baixo nível (codificação)? Como você conseguiria alternar de contexto facilmente? Como ajudar o engenheiro a apontar o repositório correto, a linha de código correta, etc.
Outro caso de uso pode ser quando novos engenheiros chegam, como você ajudaria a integrá-los facilmente para que entendam a arquitetura geral do sistema da sua equipe de ponta a ponta?
Apresentando o Modelo C4
Um jogador de CounterStrike ou PointBlank (PB) estaria muito familiarizado com o termo "C4". Mas não se preocupe, meu amigo, o "C4" que mencionei aqui não é perigoso como aquele do jogo. O C4 aqui também pode explodir, mas explode de uma visão geral grande e de alto nível em partes menores e detalhes de baixo nível.
O Modelo C4, conforme descrito neste site https://c4model.com/, afirma que é...
- Um conjunto de abstrações hierárquicas (sistemas de software, contêineres, componentes e código).
- Um conjunto de diagramas hierárquicos (contexto do sistema, contêineres, componentes e código).
- Independente de notação.
Em resumo, o Modelo C4 é um conjunto de diagramas/abstrações que explica todo o sistema em uma hierarquia do mais geral ao mais detalhado. Ele é chamado de C4 porque existem quatro "Cs" no Modelo C4: Contexto, Contêiner, Componente e Código. Todos esses quatro "Cs" estão conectados entre si.
Portanto, em um diagrama, eles serão representados da seguinte forma abaixo.
E todos esses 4 níveis ajudarão as pessoas a entenderem o sistema melhor do topo até o detalhe mais baixo, do alto nível até o detalhe muito específico. E o objetivo mais importante desse modelo C4 é a descoberta e rastreabilidade. Com esse modelo C4, podemos entender facilmente o sistema de ponta a ponta, até mesmo até o nível do código.
Nível 1: Contexto
Contexto é a porta de entrada para o sistema. Antes de discutirmos com mais detalhes sobre que tipo de serviços temos no sistema, que tipo de aplicativos temos, etc., primeiro precisamos falar sobre qual é a jornada do usuário. Um caso de uso de negócio? Atividade do usuário que está diretamente conectada ao nosso sistema.
Escopo: devemos apenas conhecer os usuários, terceiros (parceiros), sistema caixa-preta, como o negócio/sistema funciona, etc.
Público-alvo: as pessoas que devem estar presentes ao explicar isso devem ser todas as partes interessadas, começando pelo setor de Negócios (Vendas/Gerente de Parceiros/Gerente de Contas), Produto (Gerente de Produto, UI/UX, QA), Arquiteto e Desenvolvedor.
Nível 2: Contêiner
No próximo nível, quando ampliamos as caixas de Contexto, chegamos ao nível de Contêiner. Esse nível de Contêiner pode ser visto como a estrutura de equipe de uma organização. Mais especificamente, trata-se das aplicações que existem interna ou externamente na empresa. Pode ser o conjunto de microsserviços, o aplicativo (Web/Mobile/Desktop), o painel de controle, o armazenamento de dados, etc.
Escopo: ao definir o Contêiner, devemos delimitá-lo do nível do usuário ao nível da aplicação ou microsserviço. Não é necessário explicar todos os detalhes internos da aplicação ou dos microsserviços.
Público-alvo: As pessoas que podem participar ao definir esse nível devem ser qualquer pessoa do Produto (Gerente de Produto, UI/UX, QA), Arquiteto e Desenvolvedores. As pessoas do setor de negócios não são realmente necessárias nesse nível.
Nível 3: Componente
Em seguida, após definirmos o Contêiner, podemos ampliar o contêiner para mais detalhes. Aqui, podemos ver os componentes dentro do contêiner (aplicação/microsserviços).
Por exemplo, suponhamos que um Contêiner seja um Microsserviço. Se ampliarmos, podemos encontrar alguns componentes como Cron, Servidor de API, Servidor gRPC, Consumidor de Fila, etc.
Ou se, por exemplo, nosso contêiner for uma página da web, ao ampliá-lo, podemos encontrar alguns componentes como Frontend Gateway (arquitetura Backend For Frontend), SPA, etc.
Resumindo, nesse nível, podemos ver todos os componentes que existem em um contêiner. Isso explica a arquitetura completa da aplicação internamente.
Escopo: Ao definir esse nível, devemos delimitá-lo do nível do usuário até o nível do componente, como Cron, Servidor de API, gRPC, Consumidor de Fila, etc.
Público-alvo: As pessoas que podem participar ao definir esse nível devem ser apenas Arquitetos e Desenvolvedores. Negócios e Produto são opcionais, apenas se forem necessários.
Nível 4: Código
Então, após selecionarmos um componente, se ampliarmos novamente, será exibido o detalhe do código desse componente. O artefato pode ser um link para o repositório Git (Github/Bitbucket/Gitlab, etc.) ou um link para a documentação, como UML/URD/Diagrama de Classe ou qualquer coisa que possa explicar como o componente realmente é.
Escopo: Nesse nível, nos preocuparemos apenas com os detalhes da implementação do código e a documentação relacionada a ele, como UML/ERD/Diagrama de Classe, etc.
Público-alvo: As pessoas que podem participar ao discutir esse nível devem ser apenas Arquitetos e Desenvolvedores.
Exemplo Prático: Sistema de Controle de Presença dos Funcionários
Certo, eu sei que é fácil falar, mas como começar? Deixe-me guiá-lo em um mini workshop sobre como projetar meu Modelo C4. Para manter as coisas simples e fáceis, vou usar a plataforma IcePanel.io. É uma plataforma para design de sistemas. Eles oferecem um plano gratuito para brincar com seus diagramas.
Ok, sem mais delongas, aqui está um exemplo de cenário que temos.
A Tumorang Happy Employee Inc é a melhor provedora de HRIS (Sistema de Informação de Recursos Humanos) do mundo. Um de seus melhores produtos é o registrador de presença para os funcionários. E ele é usado pela maioria das empresas renomadas, como Gugel, MateMeta, MacroHard e até mesmo Mamazon.
Eles têm alguns Arquitetos de Software para lidar com seu sistema. Eles ajudam a empresa a escalar e crescer do ponto de vista arquitetônico. Um dos arquitetos é o Jack. Jack é um arquiteto habilidoso e especialista. Ele tem muitos projetos entregues para a empresa. E quanto mais a empresa cresce, mais complexo o sistema se torna. E ele começou a se sentir sobrecarregado com a complexidade de entender toda a arquitetura da organização. Houve momentos em que ele teve que alternar entre contextos ao se reunir com as pessoas. E isso é muito exaustivo.
Portanto, para melhorar a descoberta, rastreabilidade e facilitar a curva de aprendizado para os engenheiros entenderem todo o sistema, Jack quer mapear tudo na Tumorang Happy Employee Inc em um Modelo C4.
Esse é o cenário. Como podemos fazer isso? Primeiro, precisamos entender o Modelo C4. Lembre-se, é composto por Contexto, Contêiner, Componente e Código.
Nível 1: Contexto
No Nível 1 - Contexto, podemos desenhar 3 caixas grandes: Funcionários, o sistema de presença (Sistem Absensi) e um terceiro sistema (plataforma de e-mail). Nesse nível, todas as atividades do usuário podem ser listadas com setas. Mas, para simplificar, vou criar apenas uma seta direta de Funcionários => Sistem Absensi. Vamos assumir que todas as atividades do usuário estejam cobertas nessa única seta.
No diagrama acima, você também pode ver que o sistema de presença (Sistem Absensi) tem uma seta direta para o terceiro sistema (plataforma de e-mail). Independentemente da interação entre eles, vou colocar apenas uma seta direta para simplificar.
Este é o nível de Contexto, então, do ponto de vista de alto nível, desenhamos assim. Você pode improvisar com qualquer ideia criativa. Contanto que não traga detalhes de baixo nível, ainda é aceitável.
Nível 2: Contêiner
Em seguida, vamos para o Nível 2 - Contêiner. Se você selecionar o sistema de presença (Sistem Absensi) e clicar no botão de zoom, isso nos levará aos detalhes do contêiner abaixo do sistema de presença.
Aqui, vamos ver todos os contêineres no sistema de presença (Sistem Absensi). A estrutura da organização também pode ser refletida nesse nível. O contêiner pode ser um aplicativo móvel, um aplicativo da web, um aplicativo de desktop ou microserviços no backend.
Devemos ser capazes de ver a interação entre os contêineres também. Por exemplo, no diagrama, os painéis móveis e de usuário estão conectados à plataforma de autenticação. E também há uma conexão entre a plataforma de e-mail e a plataforma de notificações.
Nível 3: Componente
Em seguida, podemos selecionar um dos contêineres, por exemplo, o serviço de plataforma de notificações. É um microserviço. Em seguida, podemos ampliar para ver os componentes dentro dele.
Aqui, veremos alguns componentes que existem na plataforma de notificações, como o servidor HTTP, o servidor gRPC e os consumidores de fila.
Nível 4: Código
Na última parte, se quisermos ver os detalhes do código, podemos vincular cada componente ao repositório do GitHub. Se estivermos usando o IcePanel.io, ficará assim.
E é isso. Agora o próximo passo é continuar isso até que tudo esteja mapeado, como o Serviço de Usuário, a Plataforma de Autenticação, etc.
Uma vez que tudo esteja mapeado, teremos concluído o mapeamento do sistema geral para o modelo C4.
Conclusão
Para resumir, se desenharmos tudo em um único diagrama, a explicação do Modelo C4 seria algo como o seguinte abaixo.
Se voltarmos à história do início deste artigo, o Modelo C4 pode ajudar o arquiteto a fazer zoom in e zoom out de forma prática. Ele pode alternar rapidamente de contexto e entender facilmente todo o contexto, desde o nível mais alto até os detalhes de baixo nível. Mesmo que leve tempo, ainda ajuda muito mais do que apenas imaginar tudo.
Por exemplo, pela manhã, ele se reúne com a equipe de Pagamentos para discutir uma visão geral do planejamento (Nível C2: Container). Ao meio-dia, ele se reúne com os engenheiros para discutir a implementação do RFC (Nível C3 e C4). Com o modelo C4 em vigor, ele pode compreender todo o contexto, do mais alto ao mais baixo nível.
No entanto, acredito que chegar lá exigirá muito tempo para ser concluído. Mapear tudo dentro da organização para o modelo C4 exigirá esforços e colaboração de todos. Mas se o Modelo C4 já estiver sólido desde o início, qualquer pessoa será capaz de compreender o sistema rapidamente.
Não tenho recomendações para ferramentas específicas para mapear o modelo C4. Você pode escolher qualquer ferramenta que possa utilizar. Neste blog, utilizo o IcePanel. Existem também algumas ferramentas no mercado que podem ajudá-lo a mapear seu sistema para o Modelo C4, como Structurizr, C4-PlantUML, ou aqueles que preferem um estilo mais livre podem usar o Draw.io, Excalidraw, etc.
Acredito que isso seja tudo para a conclusão, e espero que esta postagem possa ser útil para todos. Sinta-se à vontade para compartilhar e comentar se achar que isso é útil.
Para se aprofundar em arquitetura de software indico fortemente a leitura deste livro:
Airton Lima
Referências
- Link para o Excalidraw para o diagrama detalhado:
Link para o Excalidraw - Link para o IcePanel para o resultado detalhado do workshop:
Link para o IcePanel - Você também pode obter mais informações sobre o modelo C4 em:
https://c4model.com/
Este é um artigo traduzido. O artigo original pode ser lido no link abaixo.
Iman TumorangAutor do post original — Iman Tumorang
