No DDD, um Serviço de Domínio é essencialmente apenas um Padrão de Fachada e / ou Mediador?

No Design Orientado a Domínio, a Camada de Domínio pode ter vários serviços (tradicionais). Por exemplo, para o domínio do usuário, podemos ter:

Um UserFactory, que cria objetos de Usuário de maneiras diferentes
Um UserRepository, responsável por interagir com os Persistence Services na camada de infraestrutura

Um UserService na camada de domínio é simplesmente um mediador e / ou fachada para esses dois serviços e a camada de infraestrutura, ou há mais?

object-oriented object-oriented-design domain-driven-design

— e_i_pi
fonte

Veja também Serviços em DDD e Serviços em DDD

— Erik Eidt

Eu li bastante os posts de Gorodinski, mas nunca vi o segundo link. Ótima leitura, definitivamente toca em alguns pontos importantes!

— e_i_pi

Respostas:

Domain services são melhor descritos pelo que não são:

eles não são EntitiesnemAggregate roots
eles não são Value objects
levar conhecimento de domínio que não se encaixa naturalmente em apenas um Entity ou um Value object

Um exemplo de a Domain serviceé a Saga/Process manager: coordena um processo de execução longa envolvendo múltiplos Aggregate roots, possíveis de diferentes Bounded contexts.

Dito isto, o que é Domain servicee como é implementado são duas coisas ortogonais.

Um UserService na camada de domínio é simplesmente um mediador e / ou fachada para esses dois serviços e a camada de infraestrutura, ou há mais?

Alguns serviços de domínio como a UserRepository(composto por uma interface definida na Domain layere uma implementação concreta na Infrastructure layer) podem ser implementados usando o Facadepadrão de design. Outros serviços de domínio não são.

Não existe uma regra rígida sobre como implementá-los, além da regra importante de que Domain layernão deve depender de outras camadas (e do SOLID ).

— Constantin Galbenu
fonte

Obrigado, acho que finalmente entendi a Camada de Domínio. Além de manter os objetos de dados (agregados, entidades e objetos de valor), ele também mantém as regras de negócios - mas não a implementação concreta dessas regras. Os Serviços de Domínio definem o que você pode fazer com os objetos de dados do Domínio, mas não têm conhecimento de como essas operações funcionam internamente.

— e_i_pi

As regras de negócios @e_i_pi são protegidas apenas por Agregados e suas entidades aninhadas. Os serviços de domínio não estão envolvidos nisso.

— Constantin Galbenu

@e_i_pi onde a operação envolve mais de um agregado. Por exemplo, dada a lista de Contas Bancárias (Agregadas) de uma Pessoa (outra Agregada), um serviço de domínio calcularia o saldo total dessas contas.

— Constantin Galbenu

@e_i_pi: Eu acho que você tem alguns conceitos errados. Portanto, toda a camada de domínio é um modelo de software do seu domínio. Você disse - "Junto com a retenção dos objetos de dados (agregados, entidades e objetos de valor)" - estes não são "objetos de dados" no sentido de que apenas mantêm dados; eles realmente implementam regras de domínio, eles definem o comportamento. Agora, os Serviços de Domínio , de acordo com o DDD Book de E. Evans , são aqueles aspectos do domínio que não se encaixam naturalmente em um objeto (uma entidade ou um objeto de valor).

— Filip Milovanović

Em vez disso, um Serviço de Domínio "é definido puramente em termos do que pode fazer por um cliente", definido em termos de outros elementos do modelo de domínio (para orquestrar esses elementos de alguma maneira e aplicar regras de domínio que governam essa orquestração). O serviço de domínio em si é sem estado. Há também o conceito de Application Services , que reside em uma camada de nível superior e implementa essencialmente histórias de usuários, ou casos de uso equivalentes, agindo como uma interface para a camada de domínio. Observe que a proporção dos objetos versus serviços variará dependendo do domínio que está sendo modelado.

— Filip Milovanović

Eu vejo serviços no DDD como resultado da inversão de dependência .

Se você usar dependências "simples", seu código de domínio chamaria o banco de dados para salvar ou consultar uma entidade, ou fábrica, que cria uma entidade, vinculada ao banco de dados ou serviço externo ou algum outro tipo de código de infraestrutura.

Mas não é assim que o código do domínio deve ser. O código do domínio não deve depender do código da infraestrutura. Como essa dependência dificulta o teste e, possivelmente, a reutilização. É por isso que você inverte essa dependência. Você faz com que o código de infraestrutura dependa do código do domínio. E para fazer isso, você precisa apresentar uma abstração. Uma abstração que define qual comportamento o código de domínio espera que seja implementado pela infraestrutura.

E os serviços no DDD são essa abstração. Na maioria dos casos, para o código de domínio, esses serviços devem ser interfaces simples. E a implementação deve estar no código de infraestrutura, que depende dessas interfaces.

— Eufórico
fonte

Obrigado pela sua resposta, ambas as respostas juntas me deram o "aha!" momento. Acho que sem a sua resposta, eu não teria compreendido completamente o conceito, mas prefiro a resposta de Constantine como um indicador aos futuros leitores.

— e_i_pi