Arquitetura: camadas de serviços em Domain-Driven Design

Quando desenvolvemos usando a abordagem dirigida por modelos, é preciso entender as responsabilidades e local de cada camada, e entre todas as usadas, um tipo é responsável por chamar e expor de forma abstraída e funcional todas as regras de negócio do domínio, elas são chamadas de serviços.

Os serviços podem estar em alguns locais da arquitetura do software, conforme a necessidade e a função exercida para a solução. Segundo Eric Evans, em seu livro Domain-Driven Design, os serviços são divididos ao menos em três camadas:

Aplicativo – Serviço de mais externo

  • Digere as entradas, tais como requisições em txt, xml e Json,
  • Envia mensagens para o serviço de domínio para complementação
  • Espera a confirmação,
  • Decide enviar uma notificação através de um serviço de infraestrutura

Domínio – Regras de negócios

  • Interage com objetos necessários e dispara comportamentos
  • Fornece confirmações do resultado

Infraestrutura – Mensagens e outras comunicações externas

  • Envia mensagens
  • Recebe mensagens

Mas, sem mais delongas, montei uma aplicação bem simples para demonstrar a ideia. São três projetos: Domínio, aplicação e Infraestrutura de mensagens.

Primeiro, vamos criar, no projeto de domínio, uma entidade que representa uma pessoa.

Dentro do mesmo projeto de domínio, vamos adicionar o serviço que salva a pessoa.

No projeto de Infraestrutura, iremos adicionar o serviõ de envio de mensagens.

E por fim, vamos adicionar o serviço na camada de aplicação.

Este projeto está disponível no meu GitHub no endereço a seguir:

  • https://github.com/tiagopariz/DDDServicesLayers

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *