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!
