Estrutura de camadas e Domain Driven Design

Estrutura de camadas e Domain Driven Design: mitos e fatos

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.

Mediator Pattern no Domain Driven Design

Mediator Pattern no Domain Driven Design

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 mínimo que precisa saber sobre dotnet CLI

O mínimo que você precisa saber sobre dotnet command line interface (.net CLI)

Esse artigo ‘O mínimo que precisa saber sobre dotnet CLI’ traz um material muito simples e objetivo para quem não tem muita experiência com as linhas de comando do .NET CLI. Esses comandos são fundamentais para o bom entendimento da estrutura dos projetos, bem como relacioná-los, construir ou utilizar pacotes nuget, e afins. Você pode notar que alguns desses comandos podem facilmente ser substutuídos pela alteração direta dos arquivos .csproj, mas são importantes de todo modo. Além disse note como é fácil criar um .gitignore para seu projeto ao invés de ficar procurando um.

Domain Service no Domain Driven Design

Domain Service no Domain Driven Design: eles sempre são Stateless. Veja Exemplos relacionando agregados dicas sobre as boas práticas no uso.

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.

Validation Pattern no Domain Driven Design

Validation Pattern no Domain Driven Design DDD

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.

Princípios e Acrônimos: SPOT, DRY, AHA, etc.

Entenda melhor os Princípios de design system e os acrônimos comuns: SPOT, SSOT, DRY, AHA, KISS, WET, YAGNI, SOLID, etc.

Essas siglas e acrônimos se espalham com muita facilidade por serem projetados para serem lembrados. Alguns soam bobos por forçarem muito a barra para gerar o encaixe do do explicação com o acrônimo. Além disso, alguns deles são simplesmente ideias gerais e outros são claros e definem pontos específicos na construção de projetos. Assim o artigo Princípios e Acrônimos: SPOT, DRY, AHA, etc. vai dar uma pequena visão geral sobre os mais utilizados hoje em dia. No mais, acho que eles nem sempre têm relação específica com o desenvolvimento, mas com a definição de projetos ou até mais longe: na condução das ações da vida.

Desvendando o Context Map

Entenda de uma vez por todas o que é Domain Driven Design estratégico e as nove possíveis relações entre os contextos. O DDD é uma abordagem completa para lidar com softwares grandes que tem como premissa o devido entendimento da complexidade do negócio utilizando a chamada Linguagem ubíqua. A partir daí se constrói mapas com domínios e sub-domínios. E continuando, a partir do mapa de domínios é possível extrair estruturas menores chamadas de contexto.

Diferença entre TLS e mTLS: O que você tem que saber

Diferença entre TLS e mTLS

SSL é obsoleto mas você não precisa ser. Mas qual é a diferença entre eles e como isso pode ser utilizado em sistemas distribuídos; De que modo; Quais protocolos e padrões são utilizados nessa indústria e de que modo eles e as CAs (Unidades certificadoras) suportam as aplicações modernas? Neste artigo, tentaremos esclarecer de alguma maneira perguntas como essas, como: “Diferença entre TLS e mTLS: O que você tem que saber”.

Gossip Protocol e a manutenção do estado em sistemas distribuídos

Gossip Protocol

Gossip Protocol e a manutenção do estado em sistemas distribuídos: O Gossip Protocol é um protocolo de disseminação de informações. Ele permite a manutenção de atualizações do estado em sistemas distribuídos. Desse modo, isso significa que ele garante que todos os nodos de um cluster possuam a mesma informação, garantindo o estado entre eles. Ao mesmo tempo isso é conseguido através de um mecanismo de propagação de informação. Desse modo cada nó envia sua informação atualizada para um conjunto específico de outros nós na rede. Assim esses nós retransmitem essas atualizações para outros nós, criando uma espécie de efeito de bola de neve (Ou melhor, fofoca, que é a tradução da palavra Gossip).