Desenvolvimento, Gestão, Arquitetura de Software, Estratégia, Cultura, Devops e afins
Ambas as arquiteturas são capazes de lidar com dados massivos, volumosos etc. com características particulares. O uso da Lambda é o mais popular, mas que exige mais tecnologias envolvidas, tem uma manutenção mais difícil; ao contrário da Kappa que simplifica tudo, porém pode não ter o histórico dos dados. Como de costume, trata-se de analisar um caso em específico para saber qual arquitetura se parece mais adequada.
O artigo Notification Pattern no DDD é interessante mas levanta algumas questões importantes sobre o design de código. Não é raro encontrar desenvolvedores defendendo que ele deveria ser utilizado para tudo eliminando o uso de exceptions. Por outro lado, há uma outra corrente que usa exceptions para todas as validações de negócio. Particularmente prefiro um caminho intermediário, utilizando as exceptions que interrompem o fluxo do código quando isso é fundamnetal, caso contrário entidades poderiam ficar não estáveis. Mas também utilizando o notification pattern para validações simples de entidades e quando há a construção de entidades complexas. Bom, o artigo mostrou exemplos e sobrevoou essa polêmica.
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!
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.
Como tornar seu código melhor entendendo variância de tipos? Quando falamos em variância no tratamento de tipos estamos falando dos conceitos de: variância, invariância, covariância e contravariância. Portanto, esse artigo vai explicar um pouco sobre cada conceitos com cenários práticos e a relação que eles têm com o princípio SOLID, ou mais especificamente sobre o Princípio da substituição de Liskov.
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.
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.
O domínio da aplicação deve ser sempre preservado, de modo que mudanças não o alterem e não impacte em testes. O artigo dá exemplos práticos de como pode-se utilizar esse padrão para leis, normas etc, especialmente aplicável em estruturas que precisam funcionar em conformidade. Definitivamente o padrão de especificações é muito flexível e uma boa prática.
A Factory do Domain Driven Design (DDD) é um padrão tático que pode ser utilizado de modos diferentes, com o objetivo de facilitar a geração de novos agregados. Lembre-se que a instância de objetos tem que ser fácil, mas isso nem sempre é aplicado desse modo nos códigos que vemos no dia-a-dia.