Autor: @anselme

Entre nesse link para mais detalhes: Quem é Thiago Anselme.Me chamo Thiago Anselme, natural de Petrópolis, interior do Rio de Janeiro. Casado e pai de uma menina maravilhosa e juntos cuidamos de uma vira-latinha bem bagunceira chamada Rand. Desde muito cedo eu fui interessado por TI. Meu irmão me comprou um livro de HTML quando eu tinha 10 anos e naquele período construí um site sobre pokémon.

Mediator Pattern no Domain Driven Design

Publicado em por @anselme
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

Publicado em por @anselme
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

Publicado em por @anselme
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

Publicado em por @anselme
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.

Specification Pattern no Domain Driven Design

Publicado em por @anselme

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.

Factory no Domain Driven Design

Publicado em por @anselme
Factory no Domain Driven Design (DDD)

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.

SOLID

Publicado em por @anselme
Princípio SOLID

O Princípio SOLID é um conjunto de cinco princípios de design de software criados por Robert C. Martin. Eles ajudam a criar código mais limpo, legível e fácil de manter. S de Single Responsibility, O de Open/Closed, L de Liskov Substitution, I de Interface Segregation e D de Dependency Inversion. Seguir esses princípios pode tornar o software mais flexível e robusto. #SOLID #designde software

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

Publicado em por @anselme
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.

Domain Driven Design tático

Publicado em por @anselme
Os 7 padrões do DDD Tático

O DDD pode ser observado por dois grandes pontos de vista: o estratégico e o tático. O DDD estratégico oferece elementos conceituais robustos que ligam a estruturação do software com as características particulares do negócio. Já o Domain Driven Design tático dá meios para que implementações reais, independentes de linguagem de programação, consigam garantir a entrega das necessidades estratégicas. Muitos veem o DDD apenas do ponto de vista tático – com seu conjunto de Patterns – mas entenda que somente esse ponto sem a estratégia há um empobrecimento de seu uso e, de certo modo, destrói-se a implementação do DDD. Veja nesse artigo os 7 padrões do DDD tático e como eles podem ser utilizados.