CQRS con sistemas heredados

Question

Estoy buscando convertir una aplicación basada en la web relativamente nueva con un modelo de dominio claro a más de un sistema de estilo CQRS. Mi nueva aplicación es esencialmente un reemplazo mejorado de un sistema existente anterior.

Los sistemas existentes en mi organización comparten un conjunto de bases de datos comunes, que se actualizan mediante un número incalculable de aplicaciones (desarrolladas a través del Método del Caos) que existen en silos en toda la empresa. (Tal como está, creo que ninguna persona en la empresa puede identificarlos a todos.)

Mi pregunta es, por tanto, sobre los modelos de lectura para mi aplicación. Dado que varios cambios de estado, datos generales de usuario, etc. son actualizados por otras aplicaciones fuera de mi control, ¿cuál es la mejor manera de manejar la construcción de los modelos de lectura de manera que pueda manejar actualizaciones externas, pero aún así mantener las cosas relativamente simples?

He pensado en lo siguiente hasta el momento:

1. crear vistas en la base de datos para los modelos de lectura, que lee todos los cuadros, el legado y la nueva
2. Agregar dispara a tablas existentes para actualizar nuevas tablas modelo de lectura
3. añadir algo de código a la base de datos (proc almacenado CLR/etc [SQL Server]) para actualizar un almacén de datos para los modelos de lectura fuera
4. abandonar la esperanza

¿Cuál es el consenso general sobre cómo abordar esto? ¿Es una locura pensar que puedo poner orden en un sistema heredado sin reescribir completamente todo desde cero?

Answer 1

He utilizado la opción # 1 con éxito. La creación de vistas para desmoralizar los datos para crear un modelo de lectura es una opción viable en función de la complejidad de las bases de datos de escritura. Es decir, si se trata de uniones relativamente sencillas que la mayoría de los desarrolladores pueden entender, entonces lo examinaré más de cerca para ver si es viable para usted. Sería cuidadoso con tener demasiada complejidad en estos puntos de vista.

Otra cosa a considerar es el sondeo periódico para compilar y actualizar de manera similar a las bases de datos de informes tradicionales. Aunque no es óptimo en comparación con una notificación, dependiendo de qué tan obsoleto sea su modelo de lectura, esta también podría ser una opción para observar.

Answer 2

Una vez estaba en una situación similar, los siguientes pasos fue cómo lo hice:

Para mejorar el sistema anterior y lograr más limpio base de código, la clave es hacerse cargo de la responsabilidad de escritura. Pero no seas demasiado ambicioso ya que esto puede introducir cambios en la interfaz/contrato, lo que hace que la implementación final sea riesgosa.

1. Si todas las escrituras se activan a través de algo que no sean actualizaciones directas de sql, manténgalas compatibles con versiones anteriores lo más que puedas. Tómelos como adaptadores/clientes de sus controladores de comando recientemente desarrollados.

2. Algunas de las escrituras son actualizaciones directas de sql pero fuera de su control
   Pregunte al equipo a cargo si pueden cambiar su nueva interfaz/contrato?
   Si la respuesta es no, consulte el paso 3.

3. Pregunte si pueden tolerar una posible coherencia y si desean reemplazar las actualizaciones SQL por procedimientos de la base de datos.
   En caso afirmativo, ponga todas las actualizaciones sql en los procedimientos y programe una implementación y vea el paso 4.
   Si no, tal vez debería incluirlos en su refactorización.

4. Modifique el procedimiento, reemplace las actualizaciones sql con la inserción de eventos. Y desarrolle un trabajo de backend para distribuir los eventos y publicarlos. Haga que su nueva aplicación suscriba estos eventos para disparar comandos a sus manejadores de comandos.

5. Emitir eventos de los controladores de comando y usarlos para actualizar las tablas que otras aplicaciones solían consumir.

6. Pase a la siguiente parte del sistema heredado.