La combinación de preocupaciones a menudo conduce a cosas malas en el desarrollo de software. Descubrí que casar su modelo de dominio con su lógica de persistencia es uno de los peores tipos de preocupaciones mixtas.

Nunca debe comprometer el diseño de su dominio para complacer a un marco externo.

Esta práctica tiene múltiples efectos adversos. No solo necesita dependencias de biblioteca innecesarias en su proyecto de dominio, sino que de repente le dice a su dominio cómo se almacenan los datos. La flexibilidad también se pierde. Acoplando estrechamente sus modelos con la lógica de persistencia, p. Ej. Los problemas de ORM pueden requerir que usted se relaje en las comprobaciones de invariantes de dominio, ya que los ORM generalmente requieren ciertos patrones o modificadores de acceso.

Todo se reduce a dos cosas…

Qué tan bien conoce sus herramientas y qué esfuerzo está dispuesto a hacer para separar su dominio de la persistencia.

Se necesita un poco de esfuerzo para aprender a usar correctamente el ORM de su elección, y es mucho más fácil simplemente crear modelos anémicos tontos que tienen poca o ninguna lógica, y todas las propiedades / campos son públicos con los establecedores.

Ahora, ese es un camino traicionero. Permite que existan y persistan estados no válidos; se vuelve casi imposible descifrar qué es válido o no, y más aún para los nuevos desarrolladores que se unen a su equipo.

Conozca las herramientas que tiene a su disposición. Conozca los entresijos, las deficiencias y cómo solucionarlas. Utilice la configuración fluida si su herramienta ofrece esa opción y, lo que es más importante, mantenga las preocupaciones de persistencia (infraestructura) lejos de sus modelos de dominio.

¿Ha considerado modelos de infraestructura especializada?

A veces es demasiado difícil y su ORM no quiere jugar a la pelota. Este momento exacto es donde la moral de muchos desarrolladores se desmorona y ceden a la persistencia. He estado allí. Muchas, muchas veces.

Llámelo “pragmático” si lo desea. Pero realmente no hay nada pragmático en sacrificar su dominio para complacer a un marco externo.

Últimamente, han dado exitosamente con la creación de modelos de infraestructura especializados. Estos solo son accesibles dentro de un proyecto de infraestructura. Tendrás, por ejemplo, un repositorio que recupera e hidrata los modelos de infraestructura y luego mapea y devuelve modelos de dominio.

Como resultado, su dominio es completamente independiente de la persistencia y solo conoce sus propios modelos.

Palabras de despedida

Deje de comprometer su dominio solo para facilitar el trabajo con su base de datos u ORM. Primero, aprenda su herramienta en profundidad y use cualquier configuración de modelo que proporcione (si corresponde), y trate de optar por diferentes rutas, como modelos específicos de infraestructura que se asignan directamente a modelos de dominio.

¡Mantengamonos en contacto!