Modelo C4: Simplificando a Modelagem da Arquitetura de Software

Oi, eu sou o Mauro e seja muito bem vindo!  Antes de começarmos eu queria avisar que na descrição desse video, há algumas sugestões  de livros relacionados com o assunto que será tratado. Depois de assistir o video, dá uma  conferida lá, beleza?

Então vamos começar… Você com certeza conhece a frase: uma imagem  vale mais do que mil palavras e por mais que ela seja antiga, continua sendo válida. Quer  ver um exemplo? Eu tenho quase certeza de que em qualquer lugar do mundo, você consegue  entender o que essa placa está comunicando, certo?

Bom, esse exemplo simples demonstra  a importância da chamada comunicação visual, que é objetiva, precisa e muitas vezes intuitiva. A comunicação visual é aplicada dentro do  desenvolvimento de software, pois muitas vezes é necessário criar diagramas. E você sabia que  a capacidade de criar diagramas significativos, isto é, aqueles que cumprem seu papel de  comunicação, trata-se de uma importantíssima habilidade para um desenvolvedor de software? 

Pois esses diagramas, desde que bem feitos, ajudam a representar projetos complexos de forma  objetiva. Aqui você está vendo uma reunião de desenvolvedores software. Se não existiram formas  para que essas possas possam comunicar-se de uma maneira objetiva, vários fatores podem  causar um impacto negativo e atrapalhar o entendimento sobre o que está sendo discutido  desde fatores culturais, falta de entendimento, diferenças na formação técnica ou até mesmo  como a pessoa está se sentido naquele dia, só para citar apenas alguns.

Mas veja que se  dentro de grupos de profissionais da mesma área, nem sempre a comunicação é fácil, Imagine  quando é necessário conversar e muitas vezes convencer alguém que pertence a um outro grupo  completamente diferente, como um stakeholder. Bom, eu imagino que você possa estar estar  se perguntando: Mas, Mauro e quanto aos diagramas, hein? Sim, eles deveriam ser a maneira  para preencher essas lacunas tanto entre os desenvolvedores quanto com os stakeholders, pois  seriam uma maneira de usar a comunicação visual para apresentar, discutir e entender, por exemplo  o fluxo de dados e as interações do usuário.

O problema é que na prática não é bem assim. Pra  explicar meu ponto de vista, eu vou fazer uma comparação bem simples. Olha só… Quando você pede  a um arquiteto ou a um engenheiro civil que faça o desenho da sua casa, provavelmente ele fará a  chamada planta baixa, tá certo?

Veja que você, mesmo não sendo um arquiteto ou engenheiro, vai  conseguir entender como essa casa está dividida, a disposição dos ambientes e como é possível  deslocar-se entre eles, por exemplo. Mas, se fizermos essa mesma solicitação para  um desenvolvedor de software, se você receber alguma coisa, provavelmente você vai  receber algo confuso, cheio de caixas e linhas, com uma notação inconsistente, onde há termos  ambíguos e sem indicação de tecnologia. Veja, há opções como a Unified Modeling Language (UML),  ou ArchiMate e SysML, mas elas são abandonadas por várias razões.

Uma delas é que há desenvolvedores  que consideram a aplicação delas difíceis e por isso optam por usar outras notações aparentemente  mais simples e livres. O problema é essas soluções normalmente são ineficientes, pois muitas vezes  geram diagramas confusos como os que você viu. E isso vai reforçar o argumento daqueles que  acreditam que não se faz documentação do software, uma vez que se essa documentação não é  clara e nem precisa.

Ou seja cria-se assim, um ciclo de justificativas, e veja que podem  haver várias outras, que levam as equipes de desenvolvimento a simplesmente abrir mão de  usar comunicação visual, que como já vimos, é um mecanismo muito poderoso, certo?  Bom, ainda que não exista uma solução definitiva para problema de como documentar  ou apresentar a arquitetura de um software, o chamado modelo C4 é uma das alternativas para  fazer isso. Ele foi inspirado pelo Modelo 4+1, que também tem videos aqui no canal e  tem um link para a playlist na descrição, tá bom?

O modelo C4 traz um conjunto de diagramas  hierárquicos que são usados para descrever a arquitetura de um software com diferentes níveis  de detalhe, através de uma documentação visual, onde cada um desses níveis é útil para públicos  diferentes. O nome modelo C4 vem de contexto, containers, componentes e código, que representam  cada um desses níveis. Ele pode ser usado tanto durante o projeto do software quanto para fazer  a documentação de um software já existente.

Para ajudar a entender melhor como funciona  essa organização hierárquica, O Simon Brown, o autor do modelo C4, faz uma analogia com o  Google Maps. Quando você usa o Google Maps, você aumenta o zoom para conhecer mais sobre uma  determinada área. Veja que então você pode sair da visualização de um pais inteiro, passar por uma  região, um estado, uma cidade, um bairro e chegar ao nível da rua, que seria nível mais baixo, tudo  isso de acordo com o o que você precisa conhecer.

Partindo dessa premissa, os níveis do modelo C4,  seriam como os nível de zoom do Google Maps. Você tem um nível que te fornece uma visão geral sobre  o software que está sendo desenvolvido, mas você pode passar desse nível para um outro que tenha  mais detalhes sempre que for necessário, chegando até ao nível do código. Uma dúvida recorrente  quanto ao modelo C4 e os seus níveis é a seguinte Sempre usarei os quatro níveis?

A resposta é NÃO!  Você só vai usar todos os quatro níveis quando for realmente necessário. No modelo C4, você só  usa aquilo que for agregar algum valor ao que está sendo feito.

Apenas os dois primeiros níveis,  isto é o de contexto de sistema e o de container, são considerados pelo Simon Brown, como  sendo suficientes para a maioria das equipes de desenvolvimento de software. Um outro ponto  importante que precisa ser dito sobre o modelo C4 é quanto ao seu foco Que são as estruturas  estáticas que compõem um software. Cada um dos níveis é responsável por apresentar essas  estruturas em diferentes níveis de abstração.

Todas as ideias relacionados com processos de  negócios, fluxos de trabalho, máquinas de estado, modelos de domínio, modelos de dados não cobertos  por esse modelo e por isso, quando for o caso, o modelo C4 deve ser complementado  com diagramas da UML, por exemplo. O modelo C4 não determina nenhuma notação  específica para fazer os diagramas e o que você verá nos exemplos a seguir é a mesma  notação simples que é usada na documentação oficial. A notação gráfica escolhida deve ser  capaz de mostrar as pessoas que usam os software que está sendo construído, além das estruturas  estáticas que o compõe em termos de contêineres (aplicativos, armazenamentos de dados,  microsserviços, etc.

), componentes e código. Além disso, ela deve ser fácil de ser usada,  funcionando bem em quadros brancos, folhas de papel A4, post-its e em ferramentas gráficas. Eu  vou apresentar um exemplo simples de cada um dos diagramas do modelo C4, mas cada um deles será  melhor discutido em videos específicos, tá certo?

O primeiro nível, chamado de Contexto ou  Diagrama de contexto, tem como objetivo, apresentar uma idéia geral, o contexto  em que o software está inserido. Esse diagrama mostra os sistemas e também os  usuários com os quais há alguma interação. O publico-alvo dele é o mais amplo de todos,  uma vez que não há muitos detalhes quanto a implementação, ele pode ser mostrado para  técnicos e não técnicos, estando eles dentro ou fora da equipe de desenvolvimento de software. 

Este é um exemplo de diagrama de contexto do sistema para um sistema fictício de Internet  Banking. Mostra as pessoas que o utilizam e os demais sistemas de software com os quais  o Sistema de Internet Banking se relaciona. Os Clientes PESSOA FÍSICA do banco utilizam  o Sistema de Internet Banking para visualizar informações sobre suas contas bancárias  e efetuar pagamentos.

O próprio Internet Banking System usa o Mainframe Banking  System existente do banco para fazer isso e usa o sistema de e-mail existente  do banco para enviar e-mails aos clientes. Depois de entender como seu sistema se encaixa no  ambiente, o próximo nivel, o chamado Nível 2 ou diagrama de container, é o responsável por mostrar  em alto nível a arquitetura do software. Nesse nível, as opções de tecnologia são apresentadas  juntamente com a maneira como as responsabilidades das partes que compõe a arquitetura.

O seu  sistema ele é visto como um contêiner que pode conter aplicativos, armazenamentos de dados,  microsserviços, dentre outras coisas. Este é um exemplo de diagrama de contêiner. Ele mostra mais  detalhes sobre o sistema de Internet Banking.

O diagrama apresenta quais são as partes que compõe  esse sistema, no caso são cinco contêineres: um aplicativo Web do lado do servidor, um Single page  aplicativo de página única, um aplicativo móvel, o usuário vai acessar o sistema a partir  de um desses três contamines. Além deles há também uma uma API que é usada para a comunicação  com o banco de dados, que é o quinto container, e também com os sistemas externos que haviam  sido identificados no diagrama de contexto. Notar que no banco de dados, está indicado qual  o Gerenciador de Banco de Dados que será usado.

O nível 3, chamado de diagrama de componente,  amplia os conteiners que foram identificados no nível 2 para mostrar mais detalhes. Por isso, um  diagrama de componentes pode ser criado para cada um dos containers e ele vai ser o responsável  por mostrar quem são esses componentes e qual é a responsabilidade de cada um deles. Este é um  exemplo de diagrama de componentes.

Ele apresenta alguns (em vez de todos) dos componentes que fazem  parte da container API Application. Aqui, existem três Controllers REST, com tecnologia Spring MVC  que fornecem pontos de acesso usando o protocolo HTTPS e JSON que serão usados pelo Aplicativo  Mobile e pelo Single-page Application. Cada um, desses controladores vai, subsequentemente, usar  outros componentes para acessar o sistema de banco de dados Oracle, o sistema de emails  e também os dados que estão no Mainframe.

O nível 4, é o responsável por mostrar os detalhes  de cada um dos componentes. Mas veja que apenas os componentes mais importantes ou ainda os mais  complexos devem ser modelados. A ideia geral sobre a implementação desses componente pode  ser mostrada usando diagramas de classe UML, diagramas de relacionamento de entidade ou  semelhantes.

Esse é o nível chamado de código e é considerado opcional, além disso sugere-se  que ele seja criado a partir de ferramentas automatizadas pois ele pode sofre muitas mudanças  com o tempo. Este é um exemplo parcial de diagrama de classes UML para o sistema de Internet  Banking, mostrando os elementos de código, no caso as interfaces e as classes que compõem  o componente MainframeBankingSystemFacade. Bem, depois deter visto esses exemplos, se  você é daqueles que se considera uma pessoa artisticamente limitada, cuja simples ideia  de fazer diagramas pode parecer extremamente assustadora, eu tenho uma ótima notícia!

Você  sabia que possível gerar diagramas apenas usando código-fonte? Pois é, dessa maneira conseguiríamos  documentar os nossos sistemas independentemente de nossas capacidades artísticas, bastando  escrever algo como “Serviço A usa Serviço B”, ao invés de ter que desenhar dois quadrados,  inserir um texto para identificar cada um deles e conectá-los com uma seta. Essa é a  principal motivação do que pode ser chamado de Diagram as Code, ou digrama como código  e como existem várias ferramentas que são usadas com esse objetivo, deixe-me indicar uma  delas que possui uma extensão para o VS Code.

O PlantUML permite basicamente que você escreva  um código que é automaticamente transformado em diagrama. Ele possui uma linguagem bastante  simples e permite fazer muitos tipos de diagramas, inclusive os diagramas do modelo C4 usando a  mesma notação que foi mostrada nesse video. Nesse video você teve um ideia geral sobre  o que é o MODELO C4 Que tal agora assistir a outro video do meu canal?

Pra isso basta  clicar em uma das sugestões que o Youtube está mostrando para você e na descrição há  um link para a playlist sobre o Modelo C4, não deixe de conferir. Se você gostou  desse conteúdo, compartilhe esse video deixe o seu like e inscreva-se, porque isso  vai ajudar o canal a crescer e ajudar outras pessoas. Muito obrigado por assistir até  uma próxima oportunidade e Bons estudos!