de_DEen_USes_ESfa_IRfr_FRid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Introdução

O modelo C4, desenvolvido por Simon Brown, oferece uma abordagem estruturada para a diagramação de arquitetura de software, composta por quatro níveis distintos que se aproximam progressivamente da arquitetura de um sistema de software. Cada nível fornece uma perspectiva única e serve propósitos específicos na documentação e comunicação da arquitetura de software. Vamos explorar os quatro níveis do modelo C4:

1. Diagrama de Contexto do Sistema

Escopo: Um único sistema de software.

Elementos principais: O sistema de software em escopo.

Elementos de apoio: Pessoas (por exemplo, usuários, atores, papéis, personas) e sistemas de software (dependências externas) diretamente conectados ao sistema de software em escopo.

Público-alvo: Todos, pessoas técnicas e não técnicas, dentro e fora da equipe de desenvolvimento de software.

Objetivo: Um diagrama de contexto do sistema oferece uma visão inicial e de alto nível da arquitetura de um sistema de software. Serve como ponto de partida para a documentação arquitetônica, fornecendo uma perspectiva holística do sistema em seu ambiente mais amplo. Neste diagrama, o sistema de software é representado como uma caixa central, cercada por seus usuários e outros sistemas externos com os quais interage. O foco está nas pessoas e nos sistemas de software, e não em detalhes técnicos como tecnologias ou protocolos.

Recomendado para a Maioria das Equipes: Sim.

Características principais:

  • Oferece uma visão de cima do sistema.
  • Destaca as interações entre o sistema e seus usuários/sistemas externos.
  • Ideal para comunicar com partes interessadas não técnicas.
  • O nível de detalhe é intencionalmente mantido baixo.

2. Diagrama de Containers

Escopo: Um único sistema de software.

Elementos principais: Containers dentro do sistema de software em escopo (por exemplo, aplicações web do lado do servidor, aplicações de página única, bancos de dados, etc.).

Elementos de apoio: Pessoas e sistemas de software diretamente conectados aos containers.

Público-alvo:Pessoas técnicas dentro e fora da equipe de desenvolvimento de software, incluindo arquitetos de software, desenvolvedores e equipe de operações/suporte.

Objetivo:O diagrama de contêineres aprofunda-se no sistema de software, concentrando-se em sua estrutura de alto nível e na distribuição de responsabilidades entre contêineres. Os contêineres representam unidades separadamente executáveis ou implantáveis, como aplicações web ou bancos de dados. Este diagrama também destaca as principais escolhas tecnológicas e ilustra como os contêineres se comunicam entre si. É uma ferramenta valiosa tanto para desenvolvedores quanto para a equipe de suporte/operações.

Recomendado para a Maioria das Equipes: Sim.

Características Principais:

  • Foca na arquitetura do sistema de software.
  • Mostra os contêineres e suas interações.
  • Destaca as escolhas tecnológicas.
  • Adequado para partes interessadas técnicas.
  • Não aborda detalhes específicos de implantação, como agrupamento ou balanceamento de carga.

3. Diagrama de Componentes

Escopo:Um único contêiner.

Elementos Principais:Componentes dentro do contêiner em escopo.

Elementos de Apoio:Contêineres (dentro do sistema de software em escopo) e pessoas e sistemas de software diretamente conectados aos componentes.

Público-alvo:Arquitetos de software e desenvolvedores.

Objetivo:O diagrama de componentes oferece uma visão detalhada da estrutura interna de um contêiner. Ele divide o contêiner em seus principais blocos estruturais, conhecidos como componentes. Esses componentes são responsáveis por tarefas específicas dentro do contêiner e estão associados a detalhes tecnológicos e de implementação. Este diagrama é especialmente útil para arquitetos de software e desenvolvedores que precisam compreender os aspectos mais finos da arquitetura do contêiner.

Recomendado para a Maioria das Equipes: Não, crie diagramas de componentes apenas se adicionarem valor, e considere automatizar sua criação para documentação de longa duração.

Características Principais:

  • Foca na estrutura interna de um contêiner.
  • Identifica componentes, suas responsabilidades e detalhes de implementação.
  • Dirigido a partes interessadas técnicas.
  • Nem sempre necessário e deve ser usado com cautela quando adiciona valor à documentação.

4. Diagrama de Código

Âmbito:Um único componente.

Elementos Principais:O código detalhado e os artefatos técnicos dentro de um componente específico.

Elementos de Apoio:Componentes (dentro do container em escopo), containers (dentro do sistema de software em escopo) e pessoas e sistemas de software diretamente conectados aos componentes.

Público-Alvo:Pessoas altamente técnicas, geralmente desenvolvedores e aquelas profundamente envolvidas na base de código.

Propósito:O nível final do modelo C4, o diagrama de código, zooma ainda mais para fornecer uma visão aprofundada da base de código de um componente específico. Este diagrama aprofunda-se no código-fonte real, estruturas de classes e detalhes de implementação técnica dentro do componente. É particularmente útil para desenvolvedores que precisam trabalhar com ou compreender o funcionamento interno de um componente específico.

Recomendado para a Maioria das Equipes:Raramente usado na prática. Geralmente não é comum criar diagramas de código, pois o nível de detalhe que eles fornecem é frequentemente coberto por documentação de código e ambientes de desenvolvimento.

Características Principais:

  • Foca no código-fonte real e nos artefatos técnicos.
  • Oferece uma visão extremamente detalhada da implementação de um componente.
  • Principalmente destinado a desenvolvedores que trabalham com o código.
  • Raramente usado na prática devido ao seu alto nível de detalhe, pois essas informações geralmente estão disponíveis diretamente na própria base de código.

Conclusão

Os quatro níveis do modelo C4 fornecem uma hierarquia estruturada para documentar e comunicar arquitetura de software, começando com uma visão de alto nível no diagrama de contexto do sistema e descendo gradualmente até o código real no diagrama de código. Esses diagramas atendem a diferentes públicos, desde stakeholders não técnicos que se beneficiam da visão geral até desenvolvedores altamente técnicos que necessitam de insights detalhados no nível de código. Ao utilizar o modelo C4, arquitetos de software e equipes de desenvolvimento podem transmitir de forma eficaz designs arquitetônicos complexos e promover uma melhor compreensão e colaboração dentro e fora de suas organizações.