Desenvolvimento, Gestão, Arquitetura de Software, Estratégia, Cultura, Devops e afins
Variantes e Invariantes explora esses conceitos com exemplos práticos para ajudar os leitores a compreendê-los completamente, sem que seja necessário dominar o Domain Driven Design. Em resumo, entendo que aprender isso eleva seu nível de consciência sobre arquitetura de sistemas.
Esse artigo traz as bases conceituais associadas ao paradigma Orientado a Objetos, mas não apenas as ideias de abstração, encapsulamento, etc. mas as consequências do seu uso. Por conta disso vemos, de modo geral, conceitos como Entropia de Software, Acoplamento e Coesão, e um pouquinho de código por que ninguém é de ferro.
Diferença entre Design System e Arquitetura
Esse é um debate interessante mas me parece que não deveria haver impasse. Na minha visão há também uma questão de tradução para português que nos atrapalha, mas isso também é um problema para os gringos. Design em vários cenários significa projeto e não desenho. Ou seja, design system é um conceito ligado à construção conceitual de um software, com princípios, práticas e afins. Para Eric Evans o Domain Driven é um Design, bem como o SOLID, por exemplo.
O padrão mediator é relativamente simples de entender mas pode se tornar complexo de manter. Além disso ele é muito conveniente quando se trabalha com Domain Driven Design. Assim é possível isolar agregados e garantir comunicação entre eles sem acoplamento: Entenda que isso independe se utiliza-se arquitetura monolitica ou de microserviços. Desse modo o artigo Mediator Pattern no Domain Driven Design demonstrou cenários práticos, diferenetes formas de implementar, com frameworks de terceiros ou sem. Embora os exemplos estejam em C#, eles são facilmente compreensíveis e portáveis para outras plataformas ou linguagens.
O padrão tático Domain Service é amplamente utilizado no mercado mas é bem comum ver que ele não segue as recomendações do DDD de maneira não intencional. Assim, o artigo explica como o conceito Domain Service é aplicado no mercado e aplicado no DDD em si. Após isso o vemos em detalhes e por fim vemos uma pequena implementação real de seu uso.
A validação é algo um tanto quanto básico, mas se feito do jeito errado o custo do software pode ser maior do que deveria. Algumas técnicas podem ser utilizadas de forma a garantir a consistência dos agregados e a expressividade dos códigos, reduzindo a curva de aprendizado de novos integrantes aos projetos de TI. O artigo Validation Pattern no Domain Driven Design explora o tema demonstrando algumas técnicas de referência úteis para qualquer linguagem de programação.
Modelando em 7 passos no VSCode: Veja um exemplo de uma corretora de criptomoedas do absoluto zero, passando por event storming, mapeando dos sub-domínios, relacionando contextos até chegar ao diagrama de contexto feito sob medida no Visual Studio Code.
Kubernetes: o que tem de tão especial? Essa ferramenta possui uma embricada reelação entre componentes para suportar nívels muito altos de escala e resiliência, mas a ferramenta não faz mágica. Um bom profissional por tras da manutenção do produto é absolutamente fundamental para o seu uso bem sucedido.