Já sabemos como explicitar as relações de um sistema com os demais (diagrama de contexto). Também já sabemos como explicitar a macroestrutura de um sistema através de seus contêineres (diagrama de contêineres). Agora, é hora de entendermos um pouco melhor o funcionamento de cada contêiner, utilizando o modelo C4, explicitando seus  componentes.

Contextualizando, um sistema é composto por um conjunto de contêineres. Cada contêiner é composto por um conjunto de componentes.

O que é um Componente?

Simon Brown, criador do C4 Model, explica:

Um componente é um conjunto de funcionalidades encapsuladas atrás de uma interface bem-definida.

Em linguagens Orientadas a Objeto, um componente é implementado através de uma ou mais classes. Na prática, o componente está, conceitualmente, um nível acima, em abstração, da definição de uma classe.

De forma geral, em uma aplicação MVC, são componentes: controllers, repositórios (que são serviços de domínio), demais serviços de domínio e serviços de infraestrutura.

Como elaborar um Diagrama de Componentes?

O diagrama de componentes é o “terceiro nível de detalhe” do modelo C4. Logo, o ponto de partida para elaboração do diagrama de componentes é o diagrama de contêineres.

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

Cada componente deverá ser representado por uma caixa onde deverá estar presente o nome do componente, a abstração empregada (controller, por exemplo) e um breve descritivo de sua responsabilidade. Por convenção, devemos usar um tom de cor um pouco mais claro para representar um componente do que aquele que usamos para representar o contêiner.

Com os componentes representados, adicionamos/atualizamos setas direcionadas (partindo do componente 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/contêiner de forma que apontem especificamente para o componente que implementa a relação dentro do contêiner.

Mais uma vez, não devemos nos preocupar em fazer uma descrição exaustiva de todos os componentes, sobretudo de suas relações.

Por questões de simplificação, devemos manter, fora da caixa que delimita o contêiner, apenas outros contêineres e sistemas externos com relacionamento direto ao contêiner que estamos detalhando.

De forma ilustrativa, podemos considerar o  exemplo desenvolvido por Brown:

Lições do campo

O diagrama de componentes costuma ser o mais “fácil” para o time técnico. Entretanto, em sua elaboração, acabam aparecendo responsabilidades para um contêiner que não estavam previstas no diagrama de contêiner (nível anterior de abstração). Aliás, percebe-se relação com sistemas externas que não haviam sido previstas.

Na prática, nesse ponto, chegamos em um momento onde começamos a revisitar os modelos e, de fato, ganhar compreensão sobre o sistema que está sendo explicitando.

Não havia deixado explícito até aqui, mas, sendo uma ferramenta de comunicação, os diagramas do modelo C4 são produzidos em iterações.

Hora de Agir

O diagrama de componentes é o terceiro dos 4 tipos de diagramas indicados pelo C4 model. A produção não é tão custosa, aliás, costuma ser a mais simples para o time técnico e os ganhos são enormes. Sobretudo, para identificar aspectos que não haviam surgido até então. Em outras palavras, nesse nível chegamos a um ciclo de refinamento.

Tente desenhar um diagrama de componentes para um dos contêineres de um 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.