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

Question

Estoy expandiendo/convirtiendo una aplicación de Web Forms heredada en una aplicación MVC totalmente nueva. La expansión es tanto en términos de tecnología como en caso de uso comercial. La aplicación heredada es un diseño basado en la base de datos bien hecho (DBDD). Entonces, por ejemplo, si tiene diferentes tipos de empleados como operador, supervisor, guardián de tienda, etc., y necesita agregar un nuevo tipo, solo tiene que ir y agregar algunas filas en un par de tablas y listo, su interfaz de usuario automáticamente tiene todo para agregar/actualizar el nuevo tipo de empleado. Sin embargo, la separación de capas no es tan buena.

El nuevo proyecto tiene dos objetivos principales

• extensibilidad (por la actualidad y los requisitos de tuberías futuros)
• Rendimiento

que tienen la intención de crear el nuevo proyecto reemplazando el Diseño Base de datos manejada (DBDD) con un Diseño Dirigido por Dominio (DDD) teniendo en cuenta el requisito de Extensibilidad. Sin embargo, pasar de un Diseño Dirigido por Bases de Datos a un Diseño Dirigido por Dominio parece tener un impacto inverso al requisito de Desempeño si lo comparo con el rendimiento de la aplicación DBDD heredada. En la aplicación heredada, cualquier llamada de datos desde la interfaz de usuario interactuaría directamente con la base de datos y cualquier información se devolvería en forma de un DataReader o (en algunos casos) un DataSet.

Ahora con un estricto DDD en su lugar, cualquier llamada de datos se enrutará a través de la capa Business y la capa de acceso a datos. Esto significa que cada llamada inicializaría un objeto comercial y un objeto de acceso a datos. Una sola página de UI podría necesitar diferentes tipos de datos y, al tratarse de una aplicación web, cada página podría ser solicitada por múltiples usuarios. Además de ser una aplicación web MVC sin estado, cada solicitud necesitaría inicializar los objetos de negocio y los objetos de acceso a datos en todo momento. Parece que para una aplicación sin estado MVC el DBDD es preferible a DDD para el rendimiento.

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

Answer 1

¿Ha considerado alguna forma de Separación de consultas de comandos donde las actualizaciones se realizan a través del modelo de dominio y las lecturas vienen como Lectores de datos? El DDD completo no siempre es apropiado.

Answer 2

El uso de DDD no debería tener implicaciones de rendimiento significativas en su escenario. Lo que te preocupa parece más un problema de acceso a los datos. Se refieren a ella como

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

¿Por qué es 'inicialización' caro? ¿Qué mecanismos de acceso a 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 impacto, si corresponde, en el rendimiento para la mayoría de las aplicaciones. Y siempre puede volver a cambiar las partes más sensibles al rendimiento de la aplicación a SQL sin procesar si hay un cuello de botella comprobado.

Por lo que vale la pena, NHibernate solo necesita inicializarse una vez que se inicia la aplicación, luego usa el mismo grupo de conexiones ADO.NET que los lectores de datos comunes. Por lo tanto, todo se reduce a una estrategia adecuada de asignación, búsqueda y evitar errores clásicos de acceso a datos como 'n + 1 selecciona'.

Answer 3

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

No creo que esto sea cierto, y ciertamente no es práctico. Creo que esto debe decir:

Ahora, con estricta DDD en su lugar, cualquier llamada para una transacciónserán enviados a través de la capa de negocio y la capa de acceso a datos.

No hay nada que diga que no se puede llamar a la capa de acceso a datos directamente para obtener los datos que necesita para mostrar en la pantalla. 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 enrutas todo a través de tu modelo de dominio, tendrás tres problemas:

1. Tiempo: te llevará MUCHO más tiempo implementar la funcionalidad, sin ningún beneficio.
2. Diseño del modelo: su modelo de dominio se deformará para satisfacer las necesidades de consulta en lugar de comportamiento.
3. Rendimiento: no debido a una capa adicional, sino porque no podrá obtener los datos agregados de su modelo lo más rápido que pueda directamente de una consulta. es decir, 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 obtener todas las entidades de pedido para el cliente, repetir y sumar.

Como Chriseyre2000 ha mencionado, CQRS tiene como objetivo resolver estos problemas exactos.