Tag: DDD

Operações isentas de efeitos colaterais

Publicado em por @anselme
Assim, oa reconhecer o papel dessas operações na construção de sistemas de software, os desenvolvedores são capacitados a adotar abordagens mais específicas, como a segregação de operações e a simplificação de comandos complexos. A busca pela simplicidade, aliada a práticas robustas de teste, emerge como um orientador, apontando para um caminho onde a compreensibilidade do código e a manutenção eficiente convergem. Em última análise, ao internalizar esses princípios, os desenvolvedores estão equipados não apenas com ferramentas técnicas, mas também com uma filosofia que transcende linhas de código, moldando a essência de como construímos e evoluímos sistemas de software.

Num cenário onde o código fonte é a espinha dorsal do desenvolvimento de software, compreender a natureza dos comandos, consultas e funções é algo realmente relevante. O artigo Operações isentas de efeitos colaterais delineou as características distintivas dessas operações, desde os comandos que moldam ativamente o estado do sistema até as consultas que se mantêm como observadoras passivas. Abraçando os princípios do Domain-Driven Design (DDD), exploramos estratégias para mitigar os desafios associados a efeitos colaterais e explosões combinatórias, oferecendo um guia para o desenvolvimento de sistemas mais claros e resilientes.

Interfaces reveladoras de intenções

Publicado em por @anselme
a essência de construir software significativo: a clareza nas intenções. A fundamentação de Interfaces Reveladoras de Intenções revela-se não apenas como uma prática técnica, mas como um compromisso fundamental com a comunicação eficaz entre o domínio e o código. A clareza nas intenções, desde os nomes das classes até a construção de interfaces, não é uma mera formalidade, mas uma estratatégia consistente para redução da sobrecarga cognitiva, garantindo a longedidade do sistema. Ao abraçar abstrações claras, explicitar conceitos implícitos e adotar práticas como TDD e BDD, fortalecemos não apenas a robustez do código, mas também a capacidade de evolução do software.

A essência de construir software significativo: a clareza nas intenções. A fundamentação de Interfaces Reveladoras de Intenções revela-se não apenas como uma prática técnica, mas como um compromisso fundamental com a comunicação eficaz entre o domínio e o código. A clareza nas intenções, desde os nomes das classes até a construção de interfaces, não é uma mera formalidade, mas uma estratatégia consistente para redução da sobrecarga cognitiva, garantindo a longedidade do sistema. Ao abraçar abstrações claras, explicitar conceitos implícitos e adotar práticas como TDD e BDD, fortalecemos não apenas a robustez do código, mas também a capacidade de evolução do software.

API HTTP, REST ou RESTFul

Publicado em por @anselme
O post desvela não apenas uma metodologia técnica, mas uma visão filosófica sobre a construção de sistemas distribuídos. Os princípios fundamentais de transferência de estado, a linguagem universal do HTTP e a aplicação do conceito HATEOAS não apenas conectam sistemas, mas redefinem a própria essência da interconectividade digital. Além disso, o Modelo de Maturidade de Richardson oferece uma bússola, que embora questionável ela é didática, guiando as implementações.

O post desvela não apenas uma metodologia técnica, mas uma visão filosófica sobre a construção de sistemas distribuídos. Os princípios fundamentais de transferência de estado, a linguagem universal do HTTP e a aplicação do conceito HATEOAS não apenas conectam sistemas, mas redefinem a própria essência da interconectividade digital. Além disso, o Modelo de Maturidade de Richardson oferece uma bússola, que embora questionável ela é didática, guiando as implementações.

Os 14 tipos de bancos de dados

Publicado em por @anselme
Os 14 tipos de bancos de dados: Nada impede de amanhã um novo tipo de banco de dados ganhar força, tendo em vista a variedade de dados que é crescente nos tempos atuais. Note que alguns desses bancos suportam múltiplos conceitos ao mesmo tempo. Mas ao final de tudo, analise com cuidado considerando as necessidades tecnológicas, as necessidades de negócio/custo, e as capacidades do time na hora de decidir por utilizar um tipo ou outro.

Nada impede de amanhã um novo tipo de banco de dados ganhar força, tendo em vista a variedade de dados que é crescente nos tempos atuais. Note que alguns desses bancos suportam múltiplos conceitos ao mesmo tempo. Mas ao final de tudo, analise com cuidado considerando as necessidades tecnológicas, as necessidades de negócio/custo, e as capacidades do time na hora de decidir por utilizar um tipo ou outro.

Notification Pattern no DDD

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

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.

Injeção de dependência ou Inversão de Controle

Publicado em por @anselme
Injeção de dependência ou Inversão de Controle 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 é fundamental utilizar para que o acoplamento da aplicação seja controlado, mas deve ser feito corretamente.

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!

DDD: Variantes e Invariantes

Publicado em por @anselme
O artigo DDD: 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.

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.

Estrutura de camadas e Domain Driven Design

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

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.

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.