ARQUITETURA E PADRES DE SOFTWARE Eduardo Bezerra CEFETRJ

ARQUITETURA E PADRÕES DE SOFTWARE Eduardo Bezerra (CEFET/RJ) ebezerra@cefet-rj. br

PADRÕES TÁTICOS DO DDD

Créditos 3 Apresentação baseada no livro a seguir. Eric Evans

Padrões táticos - sumário 4 Entities e Value Objects definir conceitos do domínio. Domain Service assumir responsabilidades que não se encaixam em outros objetos. Aggregates definir fronteiras entre objetos. Factories e Repositories lidar com criação e armazenamento de objetos.

Padrões Táticos do DDD 5 Entity Value Object Domain Service Aggregate Factory Repository

Entidade (Entity) 6 É um objeto que 1. 2. representa um conceito do domínio; possui identidade independente dos valores de seus atributos. A identidade de uma entidade permanece a mesma por todo o seu ciclo de vida. Exemplos: Aluno, Turma, Professor e Disciplina, etc.

Padrões Táticos do DDD 7 Entity Value Object Aggregate Factory Repository Domain Service

Objeto Valor (Value Object) 8 É um tipo de objeto usado para descrever algum aspecto do domínio e cuja identidade é baseada em seu estado. VOs são, por definição, imutáveis. � Manutenção da integridade do modelo � Vantagem: se imutável, um objeto pode ser mais facilmente compartilhado por regiões da aplicação e descartado.

Objetos Valor (Value Objects) 9 A modelagem de conceitos simples por meio de VOs é recomendada, pois permite associar comportamento a esses conceitos. � Por exemplo, em uma classe Email, é possível atribuir a responsabilidade para validar a sintaxe em um endereço de email. Forma de pensamento em consonância com o padrão VO, e com o paradigma da OO.

Objetos Valor (Value Objects) 10 Implementação de VOs (Java): � Redefinição dos métodos equals e hash. Code de forma adequada. � Qualificador final. � Nenhum método de modificação do estado.

Padrões Táticos do DDD 11 Entity Value Object Domain Service Aggregate Factory Repository

12 Serviço do Domínio (Domain Service) Há situações em que uma responsabilidade nova não se adéqua às classes já existentes. � por conta de envolver a aplicação de lógica do negócio a objetos de diferentes tipos. A atribuição a uma classe pré-existente levaria ao problemas com a coesão e acoplamento. Nessas situações, é possível criar uma classe de serviço para assumir essa responsabilidade.

13 Serviço do Domínio (Domain Service) “When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as standalone interface declared as a SERVICE. Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LANGUAGE. Make the SERVICE stateless. ” --Eric Evans

Domain Services 14 Características dos serviços de domínio: 1. 2. 3. 4. Suas operações referem-se a um conceito de domínio que não se adéqua naturalmente às entidades ou VOs. Suas operações referenciam outros objetos do domínio. Não possuem estado interno. Usualmente, são um ponto de conexão para diversos objetos do domínio.

Domain Services 15 Vantagens do uso de Domain Services: � Evita uma grande rede de conexão entre os objetos, o que resultaria em alto acoplamento. � Torna o código mais inteligível e facilita as mudanças. Mas, cuidado! O uso excessivo desse padrão pode levar a modelos de domínio anêmicos.

Domain Services 16 Cuidado: não confundir com serviços camada de aplicação. � Se a operação pertence conceitualmente à camada de aplicação o serviço deve estar lá. � Se a operação é sobre objetos de domínio e está estritamente relacionada ao mesmo, então o serviço é da camada de domínio.

Padrões Táticos do DDD 17 Entity Value Object Domain Service Aggregate Factory Repository

Agregado (Aggregate) 18 A definição de associações entre objetos de forma indiscriminada pode diminuir a flexibilidade do modelo de domínio. Um agregado é um grupo de objetos associados que são considerados como uma unidade em relação a mudanças de dados.

Agregado (Aggregate) 19 Cada agregado possui uma raiz, que é uma entidade, e é o único objeto acessível a outros externos. � define uma fronteira que protege os objetos internos a ele. � pode ter referências a qualquer objeto agregado, e os agregados podem ter referência entre eles. � Uma vez que objetos externos só podem referenciar a raiz do agregado, eles não podem alterar diretamente

Agregado (Aggregate) 20 Agregados também servem para assegurar integridade e garantir invariantes. � Invariantes são regras que devem ser mantidas mesmo que o estado de um objeto mude. Se o objeto raiz é removido da memória, todos os outros também são (já que nenhum outro objeto referencia os internos).

Agregado (Aggregate) 21 Criação de um agregado: � Escolha uma entidade para ser a raiz; � Forneça acesso aos objetos do agregado por meio da raiz;

Agregado (Aggregate) - exemplo 22 Fonte: Bezerra, 2015

Agregado (Aggregate) - exemplo 23 Fonte: DDD Book

Padrões Táticos do DDD 24 Entity Value Object Domain Service Aggregate Factory Repository

Fábrica (Factory) 25 A construção de objetos pode envolver grande conhecimento sobre sua estrutura interna, relacionamentos com outros objetos e regras a eles aplicadas. Se um objeto cliente ficar responsável por essa criação (de um objeto que lhe provê serviço), temos uma violação do encapsulamento.

Fábrica (Factory) 26 Fábricas são usadas para encapsular o conhecimento necessário à criação de objetos. � São objetos cuja responsabilidade é criar objetos de entidade ou VOs. A atribuição de criação de um objeto a sua própria classe tornaria essa classe muito complicada criar uma fábrica.

Fábrica (Factory) 27 São especialmente úteis na criação de agregados. � Isso por conta de envolver também a criação e associação de objetos componentes. � Quando a raiz do agregado é criada por uma fábrica, todos os objetos componentes também são, e todas as invariantes são asseguradas.

Fábrica (Factory) 28 Casos em que Fábricas não são necessárias são aqueles em que a criação (construção) de um objeto � não é complicada; � não envolve criação de outros, e todos os atributos necessários são passados via construtor.

Padrões Táticos do DDD 29 Entity Value Object Domain Service Aggregate Factory Repository

Repositório (Repository) 30 Representa uma coleção de entidades, agregados ou mesmo de objetos valor. Finalidade: fornecer uma abstração para um mecanismo de armazenamento persistente ao qual a aplicação faz acesso. Normalmente, são criados para manipular agregados.

Repositório (Repository) 31 Responsabilidades de um repositório: � adicionar e remover objetos de certo tipo T; � responder a consultas que solicitam subconjuntos específicos da coleção de objetos T. Provêm ignorância de persistência.

Repositório (Repository) 32 Um repositório tem o propósito de encapsular a lógica necessária à obtenção de referências a objetos. Os objetos de domínio não terão que lidar com a infraestrutura necessária na obtenção de outros objetos de domínio. � Apenas obtêm do Repositório, fazendo com que o modelo ganhe em clareza e foco.

Repositório (Repository) 33 Um repositório provê a ilusão de uma coleção “em memória principal”. Fonte: DDD Book

Conclusões

Entidades versus Objetos Valor 35 Como distinguir Entity e Value Objects. � Definir como entidade apenas aqueles conceitos do domínio que estão em conformidade com a definição de Entidade. � O resto é VO. . .

Fábricas vs repositórios 36 Ambos ajudam a gerenciar o ciclo de vida dos objetos. Factory concentra-se na criação. Repository cuida dos objetos já existentes Objetos são criados usando fábricas ou reconstituídos com o uso de repositórios.

Fábricas vs repositórios 37 Objetos são criados por uma Fábrica e depois fornecidos ao Repositório, que os armazena. Fonte: DDD Book