salary - architecture software
Servicios de dominio vs servicios de aplicaciones (3)
¿Cuál es la principal diferencia entre los servicios de dominio y de aplicación? (Estoy usando NHibernate)
¿Qué capa sería mejor para la lógica empresarial? ¿Cuál es la mejor práctica?
-S # Architecture utiliza los servicios de aplicaciones como "capa de coordinación", pero no se moleste en explicar por qué no es un servicio de dominio donde debería haber lógica empresarial.
Creo que la publicación que @Karsten cita en su comentario es más auténtica que la respuesta más votada que @ joseph.ferris publicó aquí.
Los servicios de dominio son para "un proceso o transformación importante en el dominio que no es una responsabilidad natural de un ENTIDAD o un OBJETO DE VALOR" (Eric Evans Domain-Driven Design).
Los servicios de aplicación son solo una especie de fachada o API para su aplicación (u otros consumidores externos), por lo general corresponden a un caso de uso de la aplicación y son un conjunto de operaciones de aplicación requeridas por las capas de clientes de interfaz. No contendrán lógica de negocios, o cualquier cosa que los expertos en dominios puedan venir algún día y pedir cambiar. Pueden contener gestión de transacciones (unidad de trabajo), validaciones de aplicaciones (validar el estado de los objetos recuperados de la base de datos / entrada guardada en la base de datos), validaciones de seguridad e inquietudes transversales como el registro, almacenamiento en caché, etc. y organizar objetos de dominio en modelos de vista. Son especialmente útiles cuando tiene varios clientes (por ejemplo, Web API y MVC) y las respuestas de casos de uso involucran múltiples recursos transaccionales (consulte la sección "Capa de servicio" en Patrones de arquitectura de aplicaciones empresariales por Martin Fowler).
Los servicios de aplicación pueden contener una llamada al repositorio para obtener un objeto de dominio lleno de datos, entonces pueden llamar a algún método en el objeto de dominio o un servicio de dominio y llamar nuevamente al repositorio para conservar el objeto de dominio modificado. Por lo general, son "más amplios" desde un servicio de dominio porque contienen un caso de uso completo.
Su kilometraje puede muy, pero trataré de definir en función de cómo los he usado. Independientemente de su capa de persistencia, los definiría para uso práctico como:
Servicios de dominio : servicios que existen para reforzar la integridad del dominio y facilitar la inserción, creación, eliminación y recuperación de datos del dominio. Además, los servicios de dominio pueden organizar combinaciones de objetos de dominio de nivel superior en modelos de vista. A menudo, estas son fachadas en la parte superior de los repositorios, que trabajan para ocultar algunas de las implementaciones de bajo nivel y para proporcionar una interfaz más en línea con el UL (lenguaje ubicuo) para ayudar a gestionar las expectativas.
Servicios de aplicaciones : servicios que son específicos para la implementación de un modelo de dominio o que no dependen del modelo de dominio. Un ejemplo clásico de esto sería el envío y el correo electrónico según un cambio de estado o una acción en el dominio. Esto suele ser un requisito de la aplicación en sí, y es probable que no esté especificado por el modelo de dominio. Esto puede ser ejecutado de manera procesal por un servicio de aplicación después de una llamada al servicio de dominio, o como un evento generado por el servicio de dominio.
Como dije, esto podría no coincidir con las definiciones de todos, pero esto me ayuda a asegurarme de que las preocupaciones correctas vayan al lugar correcto.
En cuanto a dónde es el mejor lugar para poner la lógica empresarial, creo que eso es complicado. Hay más de un tipo de lógica de negocios con este estilo de enfoque. Si hay un requisito lógico específico de la aplicación que no se puede definir dentro del dominio, lo pondría en la capa de servicio de la aplicación. Las cosas que afectan directamente al dominio, independientemente de la aplicación, las pondría en la capa de servicio de dominio.
El problema realmente es tomarse el tiempo para identificar lo que es un verdadero "problema de dominio". Por ejemplo, un usuario podría no ser capaz de publicar un comentario en alguna aplicación arbitraria a menos que se conozca su dirección de correo electrónico. Se podría argumentar que esto pertenece en cualquier capa. La clave es realmente ser consistente.
Los servicios de dominio son servicios dentro del dominio que consisten en múltiples clases que deben ser reutilizadas.
Los servicios de aplicaciones son clases de utilidad donde se realizan tareas técnicas, como la compresión o la mensajería SMS.
Por favor, ponga su lógica en objetos de dominio, no en servicios. Mejor reutilización en dominios complejos.