domain driven design - que - ¿Cuándo usar desarrollo impulsado por dominio y desarrollo impulsado por base de datos?
domain driven design pdf (6)
En primer lugar, para algunos antecedentes, Martin Fowler en realidad describió tres "patrones" diferentes en su libro Patterns of Enterprise Arcitecture. Script de transacción, registro activo y modelo de dominio. DDD usa el patrón de modelo de dominio para la arquitectura general y describe muchas prácticas y patrones para implementar y diseñar este modelo.
El script de transacción es una arquitectura en la que no tiene capas. El mismo fragmento de código lee / escribe la base de datos, procesa los datos y maneja la interfaz de usuario.
Active Record está a un paso de eso. Separó la interfaz de usuario, la lógica de su negocio y la capa de datos todavía viven juntos en objetos de registro activos que se modelan después de la base de datos.
Un modelo de dominio desacopla la lógica comercial que vive en su modelo de su capa de datos. El modelo no sabe nada sobre la base de datos.
Y ahora llegamos a la parte interesante:
El costo de esta separación adicional es, por supuesto, un trabajo extra. Los beneficios son una mejor capacidad de mantenimiento y flexibilidad.
El script de transacción es bueno cuando tiene pocas o ninguna regla comercial, solo desea ingresar datos y no tener pasos de verificación o toda la verificación se implementa en la base de datos.
El registro activo agrega cierta flexibilidad a eso. Como desacopla su interfaz de usuario, puede, por ejemplo, reutilizar la capa subyacente entre aplicaciones, puede agregar fácilmente algunas reglas de negocios y lógica de verificación a los objetos comerciales. Pero debido a que aún están estrechamente relacionados con los cambios en la base de datos, el modelo de datos puede ser muy costoso.
Utiliza un modelo de dominio cuando desea desacoplar su lógica comercial de la base de datos. Esto le permite manejar requisitos cambiantes más fácilmente. Domain Driven Design es un método para utilizar de manera óptima esta flexibilidad añadida para implementar soluciones complejas sin estar vinculado a la implementación de una base de datos.
Muchas herramientas hacen que las soluciones basadas en datos sean más fáciles. En el espacio de Microsoft, es muy fácil diseñar visualmente sitios web donde todo el código se encuentra justo detrás de la página web. Esta es una solución de script de transacción típica y es ideal para crear fácilmente aplicaciones simples. Ruby on Rails tiene herramientas que facilitan el trabajo con objetos de registro activo. Esta podría ser una razón para ir impulsado por los datos cuando necesite desarrollar soluciones más simples. Para aplicaciones donde el comportamiento es más importante que los datos y es difícil definir todo el comportamiento por adelantado, DDD es el camino a seguir.
¿Alguien puede tener una buena respuesta cuando se debe usar el desarrollo basado en bases de datos y cuándo se debe usar el desarrollo impulsado por el dominio? Estos dos enfoques de desarrollo tienen su importancia en sus áreas respetadas. Pero no estoy tan claro qué enfoque es apropiado en qué tipo de situación. ¿Alguna recomendacion?
Piénsalo de esta manera.
El dominio del problema existe para siempre. Sus definiciones de clase reflejarán las características eternas del dominio.
La base de datos relacional es el mecanismo de persistencia preferido de hoy. En algún punto, pasaremos de esto a algo "más nuevo", "mejor", "diferente". El diseño de la base de datos es simplemente una implementación; refleja una arquitectura de solución más que el dominio del problema.
En consecuencia, es dominio primero. Las clases reflejan el dominio del problema y las verdades universales. La base de datos relacional y ORM vienen en segundo y tercer lugar. Finalmente, complete otras cosas alrededor del modelo.
El desarrollo impulsado por el dominio es seguramente el camino a seguir. tiene más sentido y agrega flexibilidad.
Como una nota al margen de la publicación de mendelt, creo que hay un cuarto patrón: uno que está en capas, separa la lógica de busines de la persistencia y el almacenamiento, pero no usa "entidades" u "objetos de negocio". A medio punto, si se quiere, entre la secuencia de comandos de Transaction / Action y DDD.
En una buena parte de los sistemas en los que he trabajado, la capa de persistencia (repositorios) usaba SqlClient directamente y devolvía datasets a un servicio de llamadas. Los servicios realizaron decisiones y compilaron vistas que se enviaron al usuario a través del controlador. Considere que la capa de servicios es un modelo de negocio, y estaría en lo cierto, pero no era un modelo de "dominio" en el sentido DDD. Aún así, TODA la lógica de negocios ocurrió en esa capa y punto. Cada capa tenía su trabajo. Las vistas mostraban los datos, los controladores determinaban las vistas, la capa de persistencia manejaba el almacenamiento y los servicios operados entre los controladores y la persistencia.
El punto es este: DDD es un enfoque para definir un negocio a través de Ul, pruebas y código. No se trata de entidades, objetos de valor y agregados. Esas cosas son solo subproductos del enfoque purista OOP a DDD.
Solo más pensamientos para su consideración.
Para modelos comerciales complejos, prefiero una combinación de ActiveRecord y DDD. Los objetos de dominio saben cómo guardarse y las acciones de datos se realizan contra un repositorio (nHibernate puede actuar como un repositorio genérico, si miras un repositorio como algo que expone datos al modelo como una colección). La lógica comercial reside en las entidades de dominio, e incluso se puede realizar una cierta encapsulación de los tipos de valores, aunque solo cuando existe una necesidad comercial. Algunas implementaciones de DDD favorecen la eliminación de todos los organismos públicos y solo la modificación de entidades a través de métodos. No soy partidario de esa implementación a menos que haya una muy buena necesidad comercial.
Me parece que esta implementación le brinda la facilidad de uso de ActiveRecord y la encapsulación de lógica empresarial de DDD.
He hecho una pregunta similar: ¿dónde empiezo a diseñar cuando uso el mapeo O / R? Objetos o tablas de base de datos?
De las respuestas que obtuve, diría: a menos que tenga una razón concreta para usar el desarrollo basado en bases de datos, use el desarrollo impulsado por el dominio.