System design: do fascínio ao diagrama útil
Diagrama bonito sem trade-off é poster, não arquitetura.
Resposta direta
Diagrama bonito sem trade-off é poster, não arquitetura — o núcleo do material original é direto: Se você é um programador que fica fascinado toda vez que se depara com temas arquiteturais como System Design, performance de aplicações, escalabilidade, arquiteturas distribuídas e principalmente aqueles diagramas de alto nível extremamente sofisticados, talvez essa seja a hora de você começar a pensar em sair um pouco da parte do código e começar a entrar no mundo da arquitetura. E no vídeo de hoje eu vou te mostrar o passo a passo para você se tornar um arquiteto de soluções e que com toda certeza vai mudar o rumo da tua carreira.
O que o material mostra de fato
No material original, o ponto de partida não é teoria abstrata: é uma sequência concreta ligada a «System design: do fascínio ao diagrama útil». como que as coisas são decididas, como que os grandes sistemas são projetados e arquitetados e como que tudo isso é pensado nos bastidores. E se você é um programador que sente esse brilho no olhar quando o assunto é arquitetura, talvez seja a hora de você começar a sair um pouco da parte do código e começar a entrar num mundo de quem realmente toma as decisões mais importantes de um projeto, que são os arquitetos. Só que antes da gente entrar no que faz um arquiteto...
Detalhe do transcript que não pode virar genérico: arquiteto de soluções, suas responsabilidades, atribuições e o que você precisa para se tornar um, a gente precisa primeiro começar esclarecendo algumas coisas aqui que muita gente acaba fazendo confusão, que é a diferença entre um arquiteto de software e um arquiteto de soluções. Então, para início de conversa, para a coisa ficar um pouco mais clara, quando a gente fala de um arquiteto de software, a gente está literalmente falando do cara que é responsável por desenhar, projetar e arquitetar toda a estrutura inteira.
Contexto e motivação
O contexto importa porque a mesma ideia muda de preço conforme ferramenta, fase do produto ou disciplina pessoal. interna da aplicação, ou seja, é ele que vai decidir como que o sistema vai funcionar por dentro, como que vai ser feita a comunicação entre os módulos e serviços da aplicação, como que tudo isso vai ser organizado de forma coesa, reutilizável e que seja fácil de evoluir ao longo do tempo. Também é ele que vai ser o responsável por decidir quais linguagens, tecnologias e frameworks vão ser utilizados no projeto, incluindo a... até as abordagens arquiteturais.
Detalhe do transcript que não pode virar genérico: E aí, dentro dessas abordagens arquiteturais, ele pode decidir por utilizar uma arquitetura mais simples e direta ou uma arquitetura em camadas, como Clean Architecture, arquitetura hexagonal ou Onion Architecture. Só que para ele conseguir fazer tudo isso, ele precisa primeiro começar a desenvolver uma compreensão profunda do domínio do negócio. Então, antes dele começar a pensar em qualquer tipo de tecnologia, de framework ou de padrões arquiteturais, o arquiteto precisa começar primeiro entendendo...
Como funciona na prática
Em vez de colecionar slogans, trate o conteúdo como checklist operacional: o que fazer nesta semana, o que medir, o que descartar. o coração da empresa, ou seja, como que essa empresa opera, quais são os principais setores dela, quais são os que geram mais receita, quais as principais regras de negócio e como que elas se conectam. E vai ser esse conhecimento sobre o negócio que vai guiar todas as decisões técnicas e arquiteturais dali para frente. E é exatamente aqui que entra uma das abordagens mais poderosas que um arquiteto de software domina muito bem, que é o Domain Driven Design. ou design orientado a domínio, mais conhecido como DDD.
Detalhe do transcript que não pode virar genérico: Domain Driven Design é basicamente uma forma de projetar e desenvolver sistemas complexos, colocando o coração do negócio no centro da arquitetura. E é dividido em dois pilares principais, que são a modelagem estratégica e a modelagem tática. Na modelagem estratégica, o foco do arquiteto de software é total em entender e modelar o domínio do negócio. Então vai ser literalmente aqui que ele vai começar a traçar os limites arquitetos. arquiteturais da organização.
Erros comuns e armadilhas
Onde isso quebra na prática: quem tenta atalho sem o mecanismo descrito no transcript perde consistência rápido. Vai ser aqui que ele vai começar a entender os domínios e subdomínios que nada mais são do que as diferentes áreas de atuação da empresa, cada uma com as suas próprias regras, objetivos e terminologias. Também vai ser aqui que ele vai entender e aprender a lidar com um dos conceitos chaves do domínio do event design, que é a linguagem ubíqua e que vai servir para criar um vocabulário único entre os desenvolvedores e os... especialistas de domínio para facilitar a comunicação e o entendimento do problema que está sendo resolvido.
Detalhe do transcript que não pode virar genérico: E para isso ficar um pouco mais claro, caso você nunca tenha estudado sobre o domínio de event design, nunca tenha ouvido falar sobre esses termos, pensa, por exemplo, num banco. Lá dentro do banco você tem a área de contas, você tem a área de crédito, você tem a área de investimento, você tem a área de análise de risco e cada uma dessas áreas funciona com objetivos próprios, com vocabulários distintos e com regras de negócios completamente diferentes e que não... podem se misturar.
Checklist de aplicação
Na prática, isso vira rotina: escolha um experimento curto, documente antes/depois e só então escale. E aí se você tenta pegar tudo isso e colocar dentro de um único módulo da aplicação ou criar apenas um único monolito com tudo isso, o resultado vai ser um código extremamente acoplado, frágil, impossível de manter e que vai acabar virando aquele monolito ceboso que todo mundo tem a versão.
Detalhe do transcript que não pode virar genérico: Então é por isso que o arquiteto de software, antes de projetar qualquer tipo de arquitetura ou partir para qualquer implementação técnica, ele precisa primeiro entender e modelar a estratégia o negócio, para que a arquitetura da aplicação ou das aplicações reflita exatamente a realidade do negócio da empresa. E tudo isso que eu mencionei é só parte da modelagem estratégica, porque além dela a gente tem também a modelagem tática, que resumidamente é onde a modelagem de negócio começa a ser transformada em código.
Information gain
Ganho específico deste material (1061): preserve a especificidade de «System design: do fascínio ao diagrama útil» — números, ferramentas e narrativa do source, sem genificar.
Próximo passo concreto
Feche o ciclo com um próximo passo observável — sem isso, o artigo vira entretenimento e some na timeline. Então vai ser aqui que o arquiteto de software vai guiar o time técnico e definir os padrões para garantir que o código que vai ser feito pelo time de... desenvolvimento seja implementado de acordo com o mapeamento da modelagem estratégica. E é exatamente aqui que entram os famosos padrões táticos do DDD e que você muito provavelmente já se deparou por aí, que são as entidades, os aggregates, os value objects, os domain services ou serviços de domínio, as factories, o repository e por aí vai.
Detalhe do transcript que não pode virar genérico: E tudo isso que eu te falei até agora é apenas uma pequena fração das atribuições e responsabilidades de um arquiteto de software. Daria para aprofundar muito mais aqui em padrões. técnicas, conceitos, ferramentas, responsabilidades, mas isso vai ficar para um outro vídeo.