En DDD, ¿un servicio de dominio es esencialmente solo un patrón de fachada y / o mediador?

En el diseño controlado por dominio, la capa de dominio puede tener varios servicios (tradicionales). Por ejemplo, para el dominio de Usuario, podemos tener:

Una fábrica de usuarios, que construye objetos de usuario de diferentes maneras
Un UserRepository, que es responsable de interactuar con los servicios de persistencia en la capa de infraestructura

¿Es un Servicio de Usuario en la Capa de Dominio simplemente un Mediador y / o Fachada para esos dos servicios y la Capa de Infraestructura, o hay más?

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

— e_i_pi
fuente

Ver también Servicios en DDD y Servicios en DDD

— Erik Eidt

He leído mucho las publicaciones de Level Gorodinski, aunque nunca he visto ese segundo enlace. Gran lectura, definitivamente toca algunos puntos importantes!

— e_i_pi

Respuestas:

Domain services se describen mejor por lo que no son:

no son EntitiesniAggregate roots
no son Value objects
llevar conocimiento de dominio que naturalmente no se ajusta solo a uno Entity o uno Value object

Un ejemplo de a Domain servicees a Saga/Process manager: coordina un proceso de larga duración que involucra múltiples Aggregate roots, posibles desde diferentes Bounded contexts.

Dicho esto, lo que es un Domain servicey cómo se implementa son dos cosas ortogonales.

¿Es un Servicio de Usuario en la Capa de Dominio simplemente un Mediador y / o Fachada para esos dos servicios y la Capa de Infraestructura, o hay más?

Algunos servicios de dominio como un UserRepository(compuesto por una interfaz definida en el Domain layery una implementación concreta en el Infrastructure layer) pueden implementarse utilizando el Facadepatrón de diseño. Otros servicios de dominio no lo son.

No hay una regla estricta sobre cómo implementarlos, aparte de la regla importante de que Domain layerno debe depender de otras capas (y SÓLIDO ).

— Constantin Galbenu
fuente

Gracias, creo que finalmente entiendo la capa de dominio. Además de contener los objetos de datos (agregados, entidades y objetos de valor) también contiene las reglas de negocio, pero no la implementación concreta de esas reglas. Los Servicios de dominio definen lo que puede hacer a los objetos de datos de Dominio, pero no tienen conocimiento de cómo funcionan internamente esas operaciones.

— e_i_pi

Las reglas comerciales de @e_i_pi están protegidas solo por los agregados y sus entidades anidadas. Los servicios de dominio no están involucrados en esto.

— Constantin Galbenu

@e_i_pi donde la operación involucra más de un agregado. Por ejemplo, dada la lista de cuentas bancarias (agregados) de una persona (otro agregado), un servicio de dominio calcularía el saldo total de esas cuentas.

— Constantin Galbenu

@e_i_pi: Creo que tienes algunas ideas falsas. Por lo tanto, toda la capa de dominio es un modelo de software de su dominio. Usted dijo: "Junto con la retención de los objetos de datos (agregados, entidades y objetos de valor)", estos no son "objetos de datos" en el sentido de que simplemente contienen datos; estos realmente implementan reglas de dominio, definen el comportamiento. Ahora, los Servicios de dominio , según el Libro DDD de E. Evans , son aquellos aspectos del dominio que no encajan naturalmente en un objeto (una entidad o un objeto de valor).

— Filip Milovanović

Más bien, un Servicio de dominio "se define puramente en términos de lo que puede hacer por un cliente", definido en términos de otros elementos del modelo de dominio (por lo que organiza esos elementos de alguna manera y aplica las reglas de dominio que rigen esa orquestación). El servicio de dominio en sí no tiene estado. También existe el concepto de Servicios de aplicaciones , que residen en una capa de nivel superior, y esencialmente implementan historias de usuarios, o casos de uso equivalentes, al actuar como una interfaz hacia la capa de dominio. Tenga en cuenta que la proporción de los objetos frente a los servicios variará según el dominio que se esté modelando.

— Filip Milovanović

Veo servicios en DDD como resultado de la Inversión de dependencia .

Si usara dependencias "simples", entonces su código de dominio llamaría a la base de datos para guardar o consultar una entidad, o fábrica, que crea una entidad, que está vinculada a la base de datos o servicio externo o algún otro tipo de código de infraestructura.

Pero no es así como debería ser el código de dominio. El código de dominio no debe depender del código de infraestructura. Como esta dependencia dificulta la prueba y, posiblemente, la reutilización. Es por eso que inviertes esa dependencia. Hace que el código de infraestructura dependa del código de dominio. Y para hacer eso, necesitas introducir una abstracción. Una abstracción que define qué comportamiento el código de dominio espera que la infraestructura implemente.

Y los servicios en DDD son esa abstracción. En la mayoría de los casos, para el código de dominio, esos servicios deben ser interfaces simples. Y la implementación debe estar en el código de infraestructura, que depende de esas interfaces.

— Eufórico
fuente

Gracias por su respuesta, ambas respuestas juntas me han dado el "¡ajá!" momento. Creo que sin su respuesta no habría entendido completamente el concepto, pero prefiero la respuesta de Constantine como un indicador para futuros lectores.

— e_i_pi