Transición del primer proyecto de base de datos al proyecto DDD

8

Tenemos un proyecto web api c # que fue construido usando la base de datos por primera vez hace varios años. Ahora es necesario hacer una transición a la arquitectura DDD para este mismo proyecto. La razón principal de esto es poner énfasis en la lógica de negocios (que no cambió mucho) y en el diseño de la aplicación para que tenga un espacio para expandirse con nuevas funcionalidades. Obviamente, con el código de espagueti no es tan fácil hacerlo.

Como sabemos, la DDD no es solo un enfoque de código primero, sino que utiliza muchos patrones y diseños diferentes con un modelo de dominio como enfoque principal, estamos buscando algunas respuestas que hagan esta transición lo más suave posible

  • ¿Podemos crear un dominio sobre el modelo de base de datos existente? (ya que la DDD debe ser ignorancia de la persistencia, esto debería ser alcanzable)
  • ¿Podemos crear agregados a partir de objetos db existentes?
  • ¿Un nuevo proyecto desde cero (incluida la base de datos) sería una mejor opción?

Encontramos el artículo relacionado enlace pero no menciona construyendo el dominio sobre el contexto existente

    
pregunta John 24.01.2017 - 23:46

1 respuesta

4

Hicimos algo muy similar hace unos años: tomar un modelo de base de datos heredado e intentar reemplazarlo por uno nuevo y mejor estructurado, en el que todo el código nuevo utiliza solo el nuevo modelo, mientras que el sistema antiguo todavía está en uso. Para transferir esto a su caso, piense en un nuevo modelo de datos diseñado por un enfoque DDD.

A partir de esta experiencia, sugiero construir el nuevo modelo en su mayoría independiente del anterior, utilizando el mecanismo de persistencia de su elección y crear un proceso de migración sobre la marcha repetible y sobre la marcha para transferir el Los datos de "vida" existentes en la nueva estructura. Quizás también necesite un proceso de migración inversa (pero las cosas son mucho más fáciles si puede organizar su flujo de datos de manera unidireccional).

Entonces, lo que puedes hacer aquí es no construir el dominio "encima" de la base de datos existente, sino "lado a lado". Esto le permitirá utilizar la antigua base de datos y el código que se basa en ella durante un período más largo junto con la nueva estructura, que es lo que normalmente necesita para una transición sin problemas. Luego, puede aumentar las nuevas estructuras de manera incremental, construir un nuevo código sobre ellas y reemplazar las partes más antiguas del sistema paso a paso.

El inconveniente es que sus procesos de migración pueden volverse complejos con el tiempo, y si no sigue una estrategia de reemplazo rígida, podría terminar con un sistema complejo en el que tenga que mantener la mitad trabajando en las estructuras heredadas, la otra mitad En las nuevas estructuras, más los procesos de migración en sí. En nuestro caso, solo reemplazamos algunas de las peores estructuras de la antigua db y conservamos todo lo que tenía una calidad aceptable. Ya que hay una clara separación de un "backend" que trabaja en las nuevas estructuras, y un "frontend" que funciona en las viejas estructuras, esto estuvo perfectamente bien para nosotros. Pero YMMV: tienes que determinar por ti mismo lo que funciona para tu tipo de sistema.

    
respondido por el Doc Brown 30.01.2017 - 08:19

Lea otras preguntas en las etiquetas