Explicitando os Contêineres de um Sistema de Software usando o C4 Model

O que mais me agrada no C4 Model é a forma como detalhes vão sendo explicitados na medida em que avançamos na elaboração dos diagramas. Cada nível de diagrama representa um “zoom” nas informações indicadas no nível anterior.

Enquanto o diagrama de contexto, apresentado no post anterior, visa ilustrar a relação do sistema que estamos desenvolvendo com outros sistemas e com os usuários, o diagrama de contêineres, que iremos trabalhar hoje, trata da macroestrutura da aplicação.

O que é um Contêiner?

Simon Brown, criador do C4 Model, explica:

Conêineres são artefatos do sistema que hospedam dados ou código executável. Eles precisam estar em execução para que o sistema como um todo funcione.

De forma geral, um contêiner pode ser, por exemplo, um servidor web (rodando no Tomcat, no IIS, etc), uma aplicação client-side (web ou desktop), uma aplicação mobile, um microsserviço, um banco de dados, um blob, e, até mesmo, o próprio sistema de arquivos, …

Além disso, Brown atenta para o fato de que um contêiner pode ser distribuído e executado de forma isolada (preferencialmente independente). Por causa disso, a comunicação entre contêiners ocorre, geralmente, entre processos atendendo algum tipo de protocolo.

Como elaborar o diagrama de Contêineres?

O ponto de partida para a elaboração do diagrama de contêineres é o diagrama de contexto. Logo, caso não o possua, comece pela eleboração do mesmo (o post anterior explica como fazer).

Partindo do diagrama de contexto, devemos substituir a caixa que representa o sistema por um caixa vazada, com contorno pontilhado e sem preenchimento. O nome do sistema deverá estar presente na parte inferior esquerda da caixa. Os diversos contêineres do sistema serão representados no interior dessa caixa.

Cada contêiner deverá ser representado por uma caixa (ou representação mais apropriada, como no caso de um banco de dados) onde deverá estar presente o nome do contêiner, a tecnologia empregada e um breve descritivo de sua responsabilidade. Por convenção, devemos usar um tom de cor um pouco mais claro para representar um contêiner do que aquele que usamos para representar o sistema.

Com os contêineres representados, adicionamos setas direcionadas (partindo do conteiner que está acionando, chegando àquele que está sendo acionado), indicando em poucas palavras a natureza da relação.

Finalmente, devemos atualizar as setas direcionadas relacionando elementos externos ao sistema (usuários e outros sistemas) de forma que apontem especificamente para o contêiner que indica a relação dentro do sistema.

Mais uma vez, não devemos nos preocupar em fazer uma descrição exaustiva de todos os contêineres. Não é necessário, por exemplo, indicar explicitamente os diversos servidores físicos caso exista algum tipo de replicação. Por conveniência, podemos indicar esses servidores no espaço direcionado a tecnologia empregada.

O diagrama acima está disponível originalmente, como exemplo, na página do C4Model. Observe que cada passo que indiquei foi seguido aqui.

Lições do Campo

A elaboração do diagrama de contêineres não é tarefa trivial.

Em sistemas muito grandes, ou legados, é comum que não seja evidente a responsabilidade de cada contêiner (indicando claro acoplamento). Em sistemas novos ou em desenvolvimento, há uma tendência de simplificar em demasia os contêineres.

O maior ganho que tenho percebido na elaboração desse diagrama está na explicitação da complexidade dos sistemas, geralmente causada por um projeto descuidado ou pela evolução descontrolada. Para sistemas novos, esse diagrama antecipa discussões que ficariam relegadas a momentos posteriores e que, se feitas no momento certo, poderiam evitar dores de cabeça.

Hora de Agir

O diagrama de contêineres é o segundo dos 4 tipos de diagramas indicados pelo C4 model. A produção não é tão custosa e os ganhos são potencialmente enormes.

Tente desenhar um diagrama de contêiners para o sistema onde está atuando. Compartilhe suas impressões nos comentários.

Logo abaixo, há uma relação dos posts já publicados nessa série. Se ainda não os viu, recomendo a leitura.

Compartilhe este insight:

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

Uma ou duas vezes por ano tenho a oportunidade de encontrar, pessoalmente, o Ayende (líder técnico do projeto do RavenDB)....
What kind of optimizations could we expect from the C# compiler and the JIT? In this post, I would like...
In the previous post, I asked why the following code behaves differently when compilation is made in Release and Debug...
Mais uma vez, tive a honra de participar de um excelente bate-papo sobre microsserviços com o pessoal da Lambda 3....
Há tempos, venho pensando sobre “mérito”. Superficialmente, quanto dos meus resultados, positivos e negativos, se devem exclusivamente a mim? Descartando...
NOTA DO ELEMAR: Este post foi escrito por Fernando Neiva de Paiva e editado por mim. Já fui cético com...
× Precisa de ajuda?