architecture - significado - Diseño basado en dominio: Servicio de dominio, Servicio de aplicación
domain driven design tutorial (6)
Servicios de dominio: los métodos que no caben realmente en una sola entidad o que requieren acceso al repositorio están contenidos dentro de los servicios de dominio. La capa de servicio de dominio también puede contener su propia lógica de dominio y es tan parte del modelo de dominio como las entidades y los objetos de valor.
Servicios de aplicación: el servicio de aplicación es una capa delgada que se encuentra sobre el modelo de dominio y coordina la actividad de la aplicación. No contiene lógica de negocios y no posee el estado de ninguna entidad; sin embargo, puede almacenar el estado de una transacción de flujo de trabajo empresarial. Utiliza un servicio de aplicación para proporcionar una API en el modelo de dominio mediante el patrón de mensajería de solicitud de respuesta.
Millett, C (2010). Patrones de diseño profesional de ASP.NET. Publicación de Wiley. 92.
¿Alguien puede explicar la diferencia entre los servicios de dominio y de aplicación proporcionando algunos ejemplos? Y, si un servicio es un servicio de dominio, ¿pondría la implementación real de este servicio dentro del conjunto de dominio y, de ser así, también inyectaría repositorios en ese servicio de dominio? Alguna información sería muy útil.
Del Libro Rojo (Implementing Domain Driven Design, por Vaughn Vernon), así es como entiendo los conceptos:
Los objetos de dominio ( entidades y objetos de valor ) encapsulan el comportamiento requerido por el (sub) dominio, haciéndolo natural, expresivo y comprensible.
Los servicios de dominio encapsulan comportamientos que no caben en un solo objeto de dominio. Por ejemplo, una biblioteca de libros que presta un Book a un Client (con los cambios de Inventory correspondientes) puede hacerlo desde un servicio de dominio.
Los servicios de aplicaciones manejan el flujo de casos de uso, incluidas las inquietudes adicionales que se necesitan sobre los dominios. A menudo expone dichos métodos a través de su API, para el consumo por parte de clientes externos. Para basarnos en nuestro ejemplo anterior, nuestro servicio de aplicación puede exponer un método LendBookToClient(Guid bookGuid, Guid clientGuid) que:
- Recupera el
Client. - Confirma sus permisos. ( Observe cómo hemos mantenido nuestro modelo de dominio libre de preocupaciones de seguridad / administración de usuarios. Dicha contaminación podría generar muchos problemas. En su lugar, cumplimos con este requisito técnico aquí, en nuestro servicio de aplicaciones ) .
- Recupera el
Book. - Llama al servicio de dominio (pasando el
Clienty elBook) para manejar la lógica del dominio real de prestar el libro al cliente. Por ejemplo, me imagino que confirmar la disponibilidad del libro es definitivamente parte de la lógica del dominio.
Un servicio de aplicación generalmente debería tener un flujo muy simple. Los flujos de servicios de aplicaciones complejos a menudo indican que la lógica del dominio se ha filtrado fuera del dominio.
Como es de esperar, el modelo de dominio se mantiene muy limpio de esta manera, y es fácil de entender y discutir con los expertos en dominios, ya que solo contiene sus propias preocupaciones comerciales reales. El flujo de aplicaciones , por otro lado, también es mucho más fácil de administrar, ya que se alivia de los problemas de dominio y se vuelve conciso y directo.
El mejor recurso que me ayudó a comprender la diferencia entre un Servicio de Aplicación y un Servicio de Dominio fue la implementación java del ejemplo de carga de Eric Evans, que se encuentra here . Si lo descarga, puede consultar los aspectos internos de RoutingService (un Servicio de Dominio) y BookingService, CargoInspectionService (que son Servicios de Aplicación).
Mi momento de ''aha'' fue provocado por dos cosas:
- Leyendo la descripción de los Servicios en el enlace de arriba, más precisamente esta frase:
Los servicios de dominio se expresan en términos del lenguaje ubicuo y los tipos de dominio, es decir, los argumentos del método y los valores de retorno son clases de dominio adecuadas.
- Leyendo esta entrada de blog , especialmente esta parte:
Lo que encuentro una gran ayuda para separar las manzanas de las naranjas es pensar en términos de flujo de trabajo de la aplicación. Por lo general, toda la lógica relacionada con el flujo de trabajo de la aplicación termina siendo la aplicación de servicios en la capa de aplicación, mientras que los conceptos del dominio que no parecen encajar como objetos modelo terminan formando uno o más servicios de dominio.
Los servicios vienen en 3 tipos: Servicios de dominio , Servicios de aplicación y Servicios de infraestructura.
- Servicios de dominio : encapsula la lógica de negocios que, naturalmente, no encaja dentro de un objeto de dominio y NO son operaciones de CRUD típicas, que pertenecerían a un Repositorio .
- Servicios de aplicaciones : utilizados por consumidores externos para hablar con su sistema (piense en servicios web ). Si los consumidores necesitan acceso a las operaciones de CRUD, estarían expuestos aquí.
- Servicios de infraestructura : se utilizan para abstraer preocupaciones técnicas (por ejemplo, MSMQ, proveedor de correo electrónico, etc.)
Mantener los Servicios de Dominio junto con sus Objetos de Dominio es sensato, todos se centran en la lógica del dominio. Y sí, puede inyectar Repositorios en sus Servicios.
Los servicios de aplicaciones normalmente usarán tanto los servicios de dominio como los repositorios para tratar con solicitudes externas.
¡Espero que ayude!
El servicio de dominio es la extensión del dominio. Se debe ver sólo en el contexto del dominio. Esto no es una acción del usuario como, por ejemplo, cerrar una cuenta o algo así. El servicio de dominio encaja donde no hay estado. De lo contrario sería un objeto de dominio. El servicio de dominio hace algo que tiene sentido solo cuando se realiza con otros colaboradores (objetos de dominio u otros servicios). Y ese sentido tiene la responsabilidad de otra capa.
El servicio de aplicación es la capa que inicializa y supervisa la interacción entre los objetos y servicios del dominio. El flujo generalmente es así: obtenga el objeto (u objetos) del dominio del repositorio, ejecute una acción y colóquelo allí (o no). Puede hacer más, por ejemplo, puede verificar si un objeto de dominio existe o no y lanzar excepciones en consecuencia. Por lo tanto, permite al usuario interactuar con la aplicación (y probablemente de allí se origina su nombre), mediante la manipulación de objetos y servicios de dominio. Los servicios de aplicación generalmente deben representar todos los casos de uso posibles. Probablemente, lo mejor que puedes hacer antes de pensar en el dominio es crear interfaces de servicio de aplicaciones, lo que te dará una mejor idea de lo que realmente estás tratando de hacer. Tener tal conocimiento te permite enfocarte en el dominio.
En general, los repositorios pueden ser inyectados en servicios de dominio, pero este es un escenario bastante raro. Sin embargo, es la capa de aplicación la que lo hace la mayor parte del tiempo.
(Si no tienes ganas de leer, hay un resumen en la parte inferior :-)
Yo también he luchado con la definición precisa de los servicios de aplicación. Aunque la respuesta de Vijay fue muy útil para mi proceso de pensamiento hace un mes, he llegado a estar en desacuerdo con parte de ello.
Otros recursos
Hay muy poca información sobre los servicios de aplicación. Los temas como las raíces agregadas, los repositorios y los servicios de dominio se discuten ampliamente, pero los servicios de aplicación solo se mencionan brevemente o se omiten por completo.
El artículo de la Revista MSDN Una Introducción al Diseño Dirigido por Dominio describe los servicios de aplicación como una forma de transformar y / o exponer su modelo de dominio a clientes externos, por ejemplo, como un servicio WCF. Así es como Vijay describe los servicios de aplicación también. Desde este punto de vista, los servicios de aplicaciones son una interfaz para su dominio .
Los artículos de Jeffrey Palermo sobre la arquitectura de la cebolla (parte one , two y three ) son una buena lectura. Trata los servicios de aplicación como conceptos a nivel de aplicación , como la sesión de un usuario. Aunque esto está más cerca de mi comprensión de los servicios de aplicación, todavía no está en línea con mis pensamientos sobre el tema.
Mis pensamientos
He llegado a pensar en los servicios de aplicaciones como dependencias proporcionadas por la aplicación . En este caso, la aplicación podría ser una aplicación de escritorio o un servicio WCF.
Dominio
Tiempo para un ejemplo. Comienzas con tu dominio. Todas las entidades y los servicios de dominio que no dependen de recursos externos se implementan aquí. Cualquier concepto de dominio que dependa de recursos externos está definido por una interfaz. Aquí hay un posible diseño de solución (nombre del proyecto en negrita):
My Solution - My.Product.Core (My.Product.dll) - DomainServices IExchangeRateService Product ProductFactory IProductRepository
Las clases Product y ProductFactory se han implementado en el ensamblaje central. El IProductRepository es algo que probablemente está respaldado por una base de datos. La implementación de esto no es una preocupación del dominio y, por lo tanto, está definida por una interfaz.
Por ahora, nos centraremos en el IExchangeRateService . La lógica de negocios para este servicio es implementada por un servicio web externo. Sin embargo, su concepto aún es parte del dominio y está representado por esta interfaz.
Infraestructura
La implementación de las dependencias externas son parte de la infraestructura de la aplicación:
My Solution + My.Product.Core (My.Product.dll) - My.Product.Infrastructure (My.Product.Infrastructure.dll) - DomainServices XEExchangeRateService SqlServerProductRepository
XEExchangeRateService implementa el servicio de dominio IExchangeRateService mediante la comunicación con xe.com . Esta implementación puede ser utilizada por sus aplicaciones que utilizan su modelo de dominio, incluyendo el ensamblaje de la infraestructura.
Solicitud
Tenga en cuenta que no he mencionado los servicios de aplicación todavía. Los veremos ahora. Digamos que queremos proporcionar una implementación IExchangeRateService que use un caché para búsquedas rápidas. El esquema de esta clase de decoradores podría verse así.
public class CachingExchangeRateService : IExchangeRateService
{
private IExchangeRateService service;
private ICache cache;
public CachingExchangeRateService(IExchangeRateService service, ICache cache)
{
this.service = service;
this.cache = cache;
}
// Implementation that utilizes the provided service and cache.
}
¿Observa el parámetro ICache ? Este concepto no forma parte de nuestro dominio, por lo que no es un servicio de dominio. Es un servicio de aplicación . Es una dependencia de nuestra infraestructura que puede ser proporcionada por la aplicación. Vamos a presentar una aplicación que demuestra esto:
My Solution - My.Product.Core (My.Product.dll) - DomainServices IExchangeRateService Product ProductFactory IProductRepository - My.Product.Infrastructure (My.Product.Infrastructure.dll) - ApplicationServices ICache - DomainServices CachingExchangeRateService XEExchangeRateService SqlServerProductRepository - My.Product.WcfService (My.Product.WcfService.dll) - ApplicationServices MemcachedCache IMyWcfService.cs + MyWcfService.svc + Web.config
Todo esto se une en la aplicación de esta manera:
// Set up all the dependencies and register them in the IoC container.
var service = new XEExchangeRateService();
var cache = new MemcachedCache();
var cachingService = new CachingExchangeRateService(service, cache);
ServiceLocator.For<IExchangeRateService>().Use(cachingService);
Resumen
Una aplicación completa consta de tres capas principales:
- dominio
- infraestructura
- solicitud
La capa de dominio contiene las entidades de dominio y los servicios de dominio independientes. Los conceptos de dominio (esto incluye servicios de dominio, pero también repositorios) que dependen de recursos externos, están definidos por interfaces.
La capa de infraestructura contiene la implementación de las interfaces desde la capa de dominio. Estas implementaciones pueden introducir nuevas dependencias que no son de dominio que deben proporcionarse a la aplicación. Estos son los servicios de aplicación y están representados por interfaces.
La capa de aplicación contiene la implementación de los servicios de aplicación. La capa de aplicación también puede contener implementaciones adicionales de interfaces de dominio, si las implementaciones proporcionadas por la capa de infraestructura no son suficientes.
Aunque es posible que esta perspectiva no coincida con la definición general de servicios de DDD, separa el dominio de la aplicación y le permite compartir el ensamblaje del dominio (y la infraestructura) entre varias aplicaciones.