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.
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 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.
kubernetes: controllers/operators e custom resources. Entendendo os CDRs escritos em go lang e boas práticas em complementação ao Helm.