.NET - Conceitos DDD para iniciantes

.NET - Conceitos DDD para iniciantes - II

Vamos continuar apresentando alguns conceitos do Domain Drive Design (DDD) para quem esta iniciando e deseja conhecer melhor essa abordagem.

Na sequência da primeira parte do artigo vamos continuar apresentando conceitos usados na abordagem DDD.

A seguir vou apresentar o que pode ser entendido como sendo os pilares do DDD.

1- Strategic Design ou Modelagem Estratégica

O objetivo principal da modelagem estratégica é definir 3 conceitos importantes do DDD em conjunto com a equipe do projeto:

Ubiquitous Language - É a linguagem falada no dia a dia do negócio e que usa as terminologias do negócio; É a linguagem falada pelo time de desenvolvimento e pelas pessoas envolvidas em um contexto delimitado do negócio;
Bounded Context - Um Bounded Context ou Contexto Delimitado é um limite conceitual no qual um modelo de domínio é aplicável; Cada contexto possui suas responsabilidades e sua própria linguagem Ubíqua;

Context Maps - Os Context Maps ou Mapas de Contextos permitem identificar o relacionamento entre os Bounded Contexts e as equipes responsáveis por cada contexto.

O mapa de contexto é um documento, uma imagem, um rascunho cujo objetivo é facilitar o entendimento dos contextos da aplicação nos ajudando a compreender o projeto como um todo. Podemos ter diversos tipos de Context Maps com base no tipo de relacionamento entre os Bounded Contexts.

Os principais tipos de relacionamentos entre os Bounded Context são:

Shared Kernel - Indica que vários domínios são compartilhados;
Customer-Supplier-Development - Define um relacionamento entre Customer e Supplier que afetam os contextos relacionados;
Conformist - Indica a conformidade com o relacionamento;
Partner - Indica uma dependência mútua entre os contextos;
Anticorruption Layer - Indica uma camada para proteger o contexto de modificações;

Nota: Os modelos onde os limites são inconsistentes são chamados de Big ball of mud (A grande bola de lama)

2- Tatical Design ou Modelagem Tática

A modelagem tática esta relacionada com os blocos de construção da DDD podendo ser Entidades, Serviços, Repositórios, Value Objects (Objetos de Valor), Agreggates (Agregados), Events, Factories, etc., sendo um conjunto de recursos técnicos usados na construção do Modelo de domínio do negócio.

Aplicamos a modelagem tática dentro de um Contexto Delimitado usando os padrões dos blocos de construção do DDD. Sendo que um dos padrões mais importantes do projeto tático são os Agregados ou Aggregates.

A seguir temos um resumo do conceito sobre os principais blocos de construção usados na DDD: (origem)

Entities - Uma entidade é um objeto potencialmente mutável, que possui um identificador exclusivo. As entidades têm vida própria no Modelo de Domínio, o que permite obter todo o histórico de transição dessa entidade;
Value Objects - Os Value Objects são imutáveis e não possuem uma identidade única sendo definidos apenas pelos seus valores e seus atributos;
Agreggates - "Um Aggregate é composto por uma única Entity ou um conjunto de Entities e Value Objects que devem permanecer consistentes transacionalmente ao longo de toda vida do Agregado." (V.Vernon)
Services - São objetos sem estado que executam alguma lógica que não se ajusta a uma operação em uma Entity ou Value Object. Eles executam operações específicas do domínio, que podem envolver vários objetos de domínio.
Repositories - São usados principalmente para lidar com armazenamento, e abstraem responsabilidades sobre armazenamento de dados. Eles são responsáveis pela persistência de Agreggates;
Factories - São usadas para fornecer uma abstração na construção de um Objeto e podem retornar um Aggregate root, uma Entity ou um Value Object. As factories são uma alternativa para a construção de objetos com complexidade na construção através do método construtor;
Events - Indicam ocorrências significativas que ocorreram no domínio e precisam ser relatadas a outras partes interessadas pertencentes ao domínio. É comum que os Agreggates publiquem eventos.
Modules - Os módulos nos ajudam a segregar conceitos, podem ser definidos como um pacote Java ou um namespace C# e sempre seguem a Linguagem Ubíqua.

3- Architecture Design

Refere-se aos estilos de arquitetura usado na implementação do DDD como : Hexagonal, Onion, Layered, CQRS ,etc.

Uma das grandes vantagens do DDD é que ele não requer o uso de nenhuma arquitetura específica. Ao implementar o DDD, você terá que definir uma arquitetura em algum momento, e você é livre para adotar qualquer tipo de arquitetura que faça sentido para você e pode até usar diferentes tipos de arquitetura.

Assim podemos ter em cada Contexto Delimitado a implementação de uma arquitetura específica.

A seguir temos um breve resumo dos principais modelos e padrão de arquitetura que podem ser usados na implementação do DDD:

Arquitetura em Camadas

A arquitetura em camadas é sem dúvida a arquitetura mais popular e mais usada pelos desenvolvedores de hoje.
Camadas são uma forma de separação de responsabilidades, o que significa que cada camada tem uma responsabilidade específica.

Uma camada superior pode acessar uma camada inferior, mas uma camada inferior nunca pode acessar uma camada superior.

Arquitetura hexagonal (Ports & Adapters)

A arquitetura hexagonal também é conhecida como portas e adaptadores, onde portas são interfaces e adaptadores são implementações, é um tipo de arquitetura em que a camada de domínio é enfatizada.

De uma maneira prática, podemos entender como uma arquitetura em camadas onde o 'Princípio da Inversão da Dependência' foi aplicada para que a camada do domínio se tornasse a camada central que não 'depende' de qualquer outra camada.

REST

Representational State Transfer, abreviado como REST, é um estilo de arquitetura para projetar arquiteturas de software distribuídos, o REST define um conjunto de propriedades e restrições baseadas em HTTP e usa todo o potencial dos verbos HTTP.

CQRS

A Segregação de Responsabilidade por Consulta de Comando, ou CQRS, é uma arquitetura de software padrão que separa a leitura e a gravação dos dados, onde a Consulta é para leitura e o Comando para a gravação de dados.

Arquitetura Orientada a Eventos

A arquitetura orientada a eventos (Event Driven Architecture) é uma arquitetura de software, na qual existem Produtores (Pub) de eventos que geram um fluxo de eventos e Consumidores (Sub) de eventos que ouvem eventos.

Temos assim uma brevíssima descrição dos 3 principais pilares da DDD e de seus constituintes de forma a que você conheça parte dos fundamentos do DDD.

E estamos conversados...

"Sede, pois, imitadores de Deus, como filhos amados;
E andai em amor, como também Cristo vos amou, e se entregou a si mesmo por nós, em oferta e sacrifício a Deus, em cheiro suave."
Efésios 5:1,2

Referências:

José Carlos Macoratti