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:

Este é o primeiro post de uma série onde pretendo compartilhar, com considerável nível de detalhe, como resolver problemas de...
Em minha experiência, a inovação acontece a partir de um dos seguintes gatilhos: A área de negócios identifica uma demanda...
When designing systems that need to scale you always need to remember that [tweet]more computing power does not necessarily mean...
RavenDB utiliza Lucene como motor de indexação. Isso significa suporte natural a full-text search que pode ser facilmente habilitado a partir da...
No modelo C4, o diagrama de contexto descreve, com um nível de abstração bem elevado, um sistema de software indicando...
Nunca trabalhei em um circo, tampouco criei elefantes! Portanto, advirto que os “fatos” que lerá aqui foram relatados por amigos,...
× Precisa de ajuda?