Dónde poner la lógica de dominio que necesita recuperar datos de la base de datos

Question

Sé que la lógica del dominio debe colocarse en objetos de dominio. Pero, ¿qué pasa si mi lógica de dominio necesita datos de la base de datos? (por ejemplo, comprobar el valor único, los valores calculados ... etc.) Creo que inyectar repositorios en los objetos de mi dominio no es lo correcto. Además, la capa de servicio no debe contener reglas comerciales. Entonces, ¿cómo resolver este tipo de lógica de negocios?

Answer 1

Tiene razón, su objeto de dominio no debería leer los datos directamente de la base de datos. El error clásico aquí es que el objeto de dominio se envía a través de un servicio web e intenta leer datos de la base de datos cuando está en un servidor sin acceso a la base de datos.

Hay varias maneras de hacer esto:

• un servicio precargas capa cualquier información que el objeto de dominio necesitará
• el objeto de dominio puede llamar a un ayudante o repositorio que obtiene los datos de la base de datos

Answer 2

siempre he encontrado la capa de servicio a ser un lugar lógico para invocar este tipo de actividad - pero como voy a explicar, que no es donde me puso en práctica, per se. Dado que la capa de servicio es su puerta de acceso al dominio, tiene la seguridad de que cualquier solicitud que inicie la necesidad de estos datos, tendrá que pasar por este punto para llegar allí.

Además, tener servicios hablar con otros servicios es muy limpio, ya que están diseñados específicamente para requerir un mínimo esfuerzo para invocar. Puede exponer la funcionalidad adecuada que necesita en los repositorios (es decir, un método/buscador/consulta que podría darle el conteo de objetos X que coinciden con los criterios Y) y envolverlo en una llamada de servicio útil. Esto no solo le brinda más poder para realizar tareas fácilmente dentro de un solo servicio, sino que también puede aprovechar esta funcionalidad entre servicios para requisitos más complejos.

Entiendo el tipo de preocupación acerca de poner lógica de negocios en la capa de servicio, pero dependiendo de los requisitos, es una línea fina entre lo que es lógica de negocios y lo que es la lógica de negocios específica de la implementación. Al escribir un sistema, a menudo surgen reglas que están implícitas como lógicas de negocios, pero que simplemente no encajan. Las restricciones únicas son lo que he encontrado para ser el ejemplo más común. Recuerde, al igual que todo lo demás en el repositorio, esto no es una implementación en la capa de servicio, sino que es una abstracción de lo que ya está en el dominio.

Lo que hago es colocar la "lógica" en sí en el dominio, generalmente en la forma de una implementación de patrón de especificación. Dado que la lógica se ejecuta en el repositorio y no requiere que se cambie la capa de servicio, he llegado a un acuerdo con esto siendo completamente aceptable. Encontrará que las reglas que se aplican a colecciones de entidades suelen ser las "divertidas". Si solo necesita verificar que algo es único con una colección dentro de la raíz agregada, es lo suficientemente simple de hacer.

He visto enfoques donde el objeto de dominio tiene conocimiento del repositorio, y personalmente no soy un fan. El repositorio, para mí, es la definición de cómo el dominio se conectará con la capa de persistencia (aunque no siempre la implementación). El hecho de que una entidad incluso tenga conocimiento de que tiene un propósito mayor que simplemente existir complica las cosas inmensamente.