Diseño accionado por dominio con diseño basado en la base de datos para una aplicación web de MVC

Question

Estoy ampliando / convertir una aplicación de formularios web heredados en una aplicación MVC totalmente nueva. La expansión es tanto en términos de tecnología como de uso de negocios. La aplicación heredada es un diseño impulsado por la base de datos bien hecho (DBDD). Así que por ejemplo. Si tiene diferentes tipos de empleados como operador, supervisor, guarder, etc. y necesita agregar un nuevo tipo, simplemente vaya y agregue algunas filas en un par de tablas y Voila, su UI automáticamente tiene todo para agregar / actualizar el nuevo Tipo de empleado. Sin embargo, la separación de las capas no es tan buena.

El nuevo proyecto tiene dos objetivos principales

Extensibilidad
• (para requisitos de tuberías actuales y futuros)
• Performance

  Tengo la intención de crear el nuevo proyecto que reemplaza el diseño de la base de datos (DBDD) con un diseño de dominio accionado (DDD) que tenga en cuenta el requisito de extensibilidad. Sin embargo, pasar de un diseño basado en la base de datos al diseño impulsado por dominio parece impactar inversamente en el requisito de rendimiento si lo comparto con el rendimiento de la aplicación Legacy DBDD. En la aplicación heredada, cualquier convocatoria de datos de la UI interactuaría directamente con la base de datos y cualquier dato se devolverá en forma de un director de datos o (en algunos casos) un conjunto de datos.

  Ahora con un DDD estricto en su lugar, cualquier llamada para los datos se enrutará a través de la capa de negocios y la capa de acceso a datos. Esto significaría que cada llamada inicializaría un objeto de negocios y un objeto de acceso a datos. Una sola página de la UI podría necesitar diferentes tipos de datos y que es una aplicación web, cada página podría ser solicitada por varios usuarios. Además, una aplicación web de MVC es apátrida, cada solicitud necesitaría inicializar los objetos empresariales y los objetos de acceso a los datos cada vez. Por lo tanto, parece una aplicación sin estado MVC, la DBDD es preferible a DDD para el rendimiento.

  ¿O hay una manera en el DDD para lograr ambos, extensibilidad que proporciona DDD y el rendimiento que proporciona DBDD?

Answer 1

¿Ha considerado alguna forma de separación de consulta de comando donde las actualizaciones se encuentran a través del modelo de dominio, ¡aún se lee como director de datos?El DDD completo soplado no siempre es apropiado.

Answer 2

"Ahora, con un estricto DDD en su lugar, cualquier llamada para los datos se enrutará a través de la capa de negocios y la capa de acceso a los datos".

No creo que esto sea cierto, y ciertamente no es práctico. Creo que esto debería leer:

Ahora con DDD estricto en su lugar, cualquier llamada para una Transaction se enrutará a través de la capa de negocio y la capa de acceso a datos.

No hay nada que digan que no puede llamar a la capa de acceso a los datos directamente para obtener los datos que necesite mostrar en la pantalla. Es solo cuando necesita modificar los datos que necesita para invocar su modelo de dominio que está diseñado en función de su comportamiento. En mi opinión, esta es una distinción clave. Si rodea todo a través de su modelo de dominio, tendrá tres problemas:

1. Tiempo: le llevará mucho más tiempo implementar la funcionalidad, sin ningún beneficio.
2. Diseño de modelo: su modelo de dominio se incluirá en forma para satisfacer las necesidades que consultan en lugar de comportamiento.
3. Performance: no debido a una capa adicional, sino porque no podrá obtener los datos agregados de su modelo tan rápido como pueda directamente de una consulta. I.E. Considere el valor total de todos los pedidos realizados para un cliente en particular, es mucho más rápido escribir una consulta para esto que para buscar todas las entidades de pedidos para el cliente, iterar y suma.

   Como ha mencionado ChriseYRE2000, CQRS apunta a resolver estos problemas exactos.

Answer 3

Uso de DDD no debe tener implicaciones de rendimiento significativas en su escenario.Lo que le preocupa parece más como un problema de acceso a datos.Te refieres a ella como

Inicializar un objeto de negocio y un objeto de acceso a datos

¿Por qué está "inicializando" caro?¿Qué mecanismos de acceso a los datos estás usando?

DDD con objetos de larga duración almacenados en una base de datos relacional generalmente se implementa con ORM. si se usa correctamente , ORM tendrá muy poco, si corresponde, un impacto en el rendimiento para la mayoría de las aplicaciones.Y siempre puede volver a encender las partes más sensibles al rendimiento de la aplicación a SQL RAW si hay un cuello de botella comprobado.

Por lo que vale la pena, NHibibernate solo debe inicializarse una vez en la puesta en marcha de la aplicación, después de eso, utiliza el mismo grupo de conexión ADO.NET que sus lectores de datos regulares.Por lo que todo se reduce a un mapeo adecuado, recuperando la estrategia y evitando los errores de acceso de datos clásicos como 'N + 1 Selecciona'.