Especificaciones
Los Domain service deben ser similares a los Application service, con lo que no debe superar el nivel de complejidad 3.
Su principal cometido es cubrir todas aquellas acciones o reglas del negocio que no sean responsabilidad de un Aggregate.
Como características más concretas, puede cambiar el estado objetos de tipo Domain. Cuando hay dos Aggregates que se influencian entre ellos, mejor usar un servicio que lo gestione. Por ejemplo, un Finder. Otras veces, se usan para construir objetos complejos de tipo Domain usando composición.
Se relaciona con el Command use case, Aggregate root, Aggregate y Value objects. En ocasiones también con Query use case.
Como observación, puede que os hayáis dado cuenta que no se relaciona habitualmente con Query use case. Eso es debido a que las Querys no alteran el estado del dominio, con lo que sería muy extraño que en circunstancias normales existiese dicha relación.
¿Qué valor me aporta implementar un Domain service?
- Libera al caso de uso de los pequeños detalles que se suelen gestionar cuando tratamos con reglas de dominio. Así, cuando haya otro caso de uso que lo necesite, esos pequeños detalles estarán ya resueltos y concentrados.
- Si nos lo montamos bien, sólo con los servicios de dominio podemos ver las reglas que rigen nuestro dominio a nivel de relaciones entre sus elementos.
¿Cómo se expresa esta carta en el mundo real?
Como indican los iconos de arriba a la izquierda, corresponde a una clase, que contendrá la funcionalidad y como estructura organizativa, es interesante dejar dichas clases dentro de una carpeta.
|
|