Desenvolvimento, Gestão, Arquitetura de Software, Estratégia, Cultura, Devops e afins
Essa é uma confusão comum em muitos devs. O artigo Injeção de dependência ou Inversão de Controle explica SOLID, fala sobre diversos injetores de depenência, explica algumas particularidades que eles possuem. Além disso há exemplos tanto em linguagens de backend quando em frontend. De modo geral utilize injeção de dependência para reduzir o acoplamento. Mas, faça corretamente!
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.