¿Las anotaciones de persistencia en objetos de dominio son una mala práctica?

¿Las anotaciones de persistencia en objetos de dominio son una mala práctica?

Sí. Con el auge de NoSQL, no puede confiar en una sola estrategia de persistencia.

Por ejemplo, hoy estoy persistiendo mis objetos de dominio (digamos usando morfina) en MongoDB. ¿Qué pasa si mañana quiero persistir objetos de dominio en Neo4j ?

O bien, uno podría querer persistir objetos de dominio en los tres tipos de bases de datos como relacional (Postgres / MySQL), MongoDB(almacén de documentos) y Neo4J(base de datos de gráficos) solo para evaluar.

En todos estos casos, es mejor tener una estrategia de persistencia separada en lugar de depender solo de objetos de dominio

Mejor práctica : Pasar la estrategia persistente como un patrón de estrategia podría ayudar. Pero hay que tener cuidado al diseñar sus clases / objetos.

Recientemente he trabajado en un sistema razonablemente complejo con una capa de persistencia separada, y fue un gran dolor en el culo y muy malo para la mantenibilidad. Básicamente estás viendo un conflicto entre los principios de YAGNI y la Responsabilidad Individual. En mi opinión, YAGNI es el más importante (por desgracia, también el más frecuentemente ignorado).

Diría que en la gran mayoría de los casos, es mucho mejor persistir objetos de dominio directamente si está utilizando un OR, a menos que tenga requisitos concretos que obligan a las entidades de persistencia a estructurarse de manera diferente (si tienen exactamente la misma estructura, no hay razón para separarlas excepto los argumentos de la torre de marfil).

Para estar seguro: siempre haga el material de persistencia real (llamando a funciones OR) en una capa de servicio/DAO separada! De esa manera, es fácil introducir una capa de persistencia más adelante si encuentra que la necesita.

En mi opinión no hay necesidad de duplicar los objetos de dominio para poder separarlos de su capa de persistencia. Funciona código duplicado en la mano y es perfectamente factible mediante el uso de los mismos objetos que DTO. Si es necesario, siempre se puede utilizar clases separadas si es necesario, pero yo no lo haría una regla de oro, que 'll costar tiempo y todos sabemos que el tiempo es valioso.

Creo que usaré anotaciones en mi dominio si ya estoy decidido con el framework de persistencia que voy a usar, sin embargo, XML sería más conveniente si sigues la arquitectura Hexagonal y TDD. Si anota su dominio con un marco específico por adelantado, se combinará con la integración de persistencia y no podrá probar la funcionalidad principal con el objetivo de ser agnóstico de la tecnología/marco.

Respuesta corta: Me gustan los objetos persistentes, ricos y de dominio.

Respuesta larga:

Durante casi 10 años trabajé en un sistema bastante grande ~ 500k LOC usando Resorte e Hibernación. Al principio, comenzamos con un enfoque de" script de transacción " (ver Fowler), en parte porque no confiábamos en Hibernate. Sin embargo, en poco tiempo, llegamos a confiar en Hibernate y debido a mi entrenamiento mucho más temprano en OO bastante purista, me convertí en un gran creyente en la persistencia transitoria combinada con un Enfoque de Diseño impulsado por el dominio. Básicamente llegamos a pensar que nuestro sistema estaba respaldado con un ODBMS (con muchas fugas pequeñas :-)).

Llamé a nuestra arquitectura un "núcleo de dominio" porque el libro DDD aún no había sido escrito. Esto fue en los primeros días de Hibernación, por lo que el modelo de dominio no estaba contaminado con anotaciones. La preocupación separada de persistencia se mantuvo separada en asignaciones XML.

De nuevo, con el tiempo, mejoramos en el comportamiento de empujar hacia abajo en la capa de dominio. Teníamos un controlador bastante tradicional scheme>service d>dao> > domain layering scheme que se aplicaba con dependencias en tiempo de compilación. Lo que observé con el tiempo es que este modelo funcionó muy bien para nuestro sistema, que representó cada faceta del dominio bastante complejo de la administración del plan 401(k), incluida la configuración del plan, el comercio, la contabilidad, las pruebas de cumplimiento, las ventas, la marca, etc. Un modelo de dominio rico con persistencia "mágica" (relativamente) transparente fue clave para poder construir nuevos características en términos de características existentes en el modelo de dominio.

Nuestra capa de servicio solo orquestó las interacciones entre servicios técnicos (como correo electrónico, E/S de archivos, colas, etc.).) y ayudó a abarcar paquetes de dominio cuando era necesario. La capa de servicio también definió el límite de transacción (a través de Spring). Servicios solo recibidos o emitidos DTO o primitivos. Mucha gente odia eso, como un descanso en SECO, pero nos pareció que nos mantuvo honestos a la hora de definir las interfaces de servicio y el código que los usó. También hizo que fuera muy fácil remotear cosas más tarde.

Este enfoque nos permitió construir software de alta calidad con un equipo bastante pequeño (éramos un equipo Scrum).

Entonces, considérame un creyente en los objetos de dominio persistentes. No sé si mi historia ayuda, pero quería compartirla.

Preferiría objetos de dominio enriquecido que tengan las anotaciones en él. Incluso Evans utiliza este enfoque en su aplicación de ejemplo. Utiliza XMl en lugar de Anotaciones, pero todavía persiste los mismos objetos.

Tal vez sea más limpio separar el dominio y la persistencia, pero no lo hagas solo para poder elegir una tecnología de base de datos diferente en el futuro. Es el camino hacia el infierno de la complejidad y el señor YAGNI te morderá.