Refactorización en diseño dirigido por dominio [cerrado]

Acabo de comenzar a trabajar en un proyecto y estamos usando un diseño basado en dominio (como lo define Eric Evans en Diseño dirigido por dominio: abordar la complejidad en el corazón del software . Creo que nuestro proyecto es ciertamente un candidato para este diseño patrón como lo describe Evans en su libro.

Estoy luchando con la idea de refactorizar constantemente.

Sé que la refactorización es una necesidad en cualquier proyecto y sucederá inevitablemente a medida que cambie el software. Sin embargo, en mi experiencia, la refactorización ocurre cuando cambian las necesidades del equipo de desarrollo, no como la comprensión de los cambios de dominio ("refactorización para una mayor comprensión" como lo llama Evans). Estoy más preocupado por los avances en la comprensión del modelo de dominio. Entiendo hacer pequeños cambios, pero ¿qué pasa si es necesario un gran cambio en el modelo?

¿Cuál es una forma efectiva de convencerte a ti mismo (y a otros) que deberías refactorizar después de obtener un modelo de dominio más claro? Después de todo, la refactorización para mejorar la organización o el rendimiento del código podría estar completamente separada de lo expresivo en términos del código de lenguaje ubicuo. A veces parece que no hay suficiente tiempo para refactorizar.

Afortunadamente, SCRUM se presta a la refactorización. La naturaleza iterativa de SCRUM hace que sea fácil construir una pieza pequeña y cambiarla. Pero con el tiempo esa pieza se hará más grande y ¿qué pasa si tienes un avance después de que esa pieza es tan grande que será demasiado difícil de cambiar?

¿Alguien ha trabajado en un proyecto que emplea diseño impulsado por dominio? Si es así, sería genial tener una idea de esto. Especialmente me gustaría escuchar algunas historias de éxito, ya que DDD parece muy difícil de acertar.

¡Gracias!

He sido un gran fanático de DDD por un tiempo (con y sin la red de seguridad de un marco de prueba).

Todo el concepto y el ciclo de vida de la refactorización no cambian porque ahora está utilizando una nueva metodología de diseño. Si tomará un tiempo significativo, tiene que tener un beneficio proporcional para el proyecto a fin de obtener ese tiempo de la gerencia.

Con respecto a hacerlo: en un caso, participé en una refactorización importante de 3 meses debido a un 'avance' en la comprensión del modelo de dominio. Se requieren pruebas para verificar el comportamiento actual, pruebas para verificar el comportamiento esperado y cambios en el código de llamada. Sin embargo, los beneficios fueron significativos y le permitieron al negocio hacer muchas más cosas que tenía que hacer antes pero que simplemente no pudo. En esencia, la refactorización fue esencialmente una 'característica'.

Creo que la refactorización en el diseño impulsado por dominio se debe a una necesidad, no a un refactor "agradable". Tan pronto como identifique un modelo de dominio incorrecto, el código / sistema no representa el problema del mundo real.

Caso en cuestión, recientemente trabajamos en una aplicación de complejidad de dominio razonable. Era un sistema de facturación / contrato, y estábamos introduciendo un nuevo tipo de tarifa. Estábamos usando un proceso ágil, scrums de 2 semanas para ser precisos.

Inicialmente identificamos en el modelo que las 2 tasas estaban completamente separadas y no tenían ninguna relación, excepto a través del Contrato. Sin embargo, a medida que completamos más historias, nos dimos cuenta de que en realidad eran las mismas, especialmente cuando comenzamos a ajustar la nueva tarifa como una vieja solo para que funcionara. Esta fue la primera señal de advertencia.

Para acortar la historia, pudimos completar el 90% de las historias con el modelo incorrecto, pero llegamos al punto en el que en cada parte del código estábamos envolviendo la nueva tarifa como una antigua, y / o creando if newRate else oldRate CADA donde. Estábamos golpeando nuestras cabezas contra el proverbial muro de ladrillos. Estábamos a la mitad de esta parte del proyecto y sabíamos que el tiempo para completar será exponencial o inviable con el modelo de dominio incorrecto. Así que mordimos la bala, dividimos una historia en otras ocho historias y refactorizamos el Modelo de Dominio.

Cuando completamos el proyecto, sabíamos en retrospectiva que era lo correcto y lo ÚNICO para hacerlo bien.

¿Tomó tiempo? Sí, pero si no lo hiciéramos, habría tomado más tiempo. ¿Fue DDD bien hecho? Bueno, curiosamente no sabíamos sobre DDD en ese momento, pero poco después asistimos a un taller de DDD de Eric Evans, y todo lo que yo y mis colegas pudimos hacer fue asentir. Creo que si supiéramos DDD, habríamos recogido el refactorizador mucho antes ahorrando así más tiempo.

Si algo falla en el modelo de dominio, es importante corregirlo. En mi experiencia, perdimos un poco en cómo el modelo de dominio se conecta a sus diferentes entidades cuando implementamos parte de él.

Esto resultó en que la gente solía modelar de una manera que no estaba destinada y, por lo tanto, rompe otras partes del modelo para tratar de "hacer que funcione".

Tan pronto como se dé cuenta de que hay algo mal en el modelo de dominio, cámbielo lo más rápido posible. Cuanto más tarde antes de refactorizarlo, más difícil será cambiar con respecto a los usuarios, cuyos modelos mentales ahora están adaptados.

Para algunas partes del código, la refactorización continua es exagerada. Para alguna otra parte del código (en DDD, el llamado dominio principal ) es una necesidad. Comprender que el código no es como debería ser supone una carga cognitiva adicional para el desarrollador (la diferencia entre nuestra comprensión del dominio y la implementación actual) que hará que las evoluciones posteriores sean más difíciles y / o costosas.

La pregunta es: "¿serán necesarias estas evoluciones?". En el dominio principal (el área que está haciendo una diferencia comercial) la respuesta es "¡Sí!". Porque esa es la poción del dominio que preocupa más al negocio y el que marcará la diferencia para las partes interesadas. Ese es el lugar donde desea mantener su código en perfecto estado, listo para implementar el próximo requisito con un mínimo esfuerzo, debido a la flexibilidad de su Modelo de Dominio.

Sin embargo, eso será costoso cuando se aplique a todo el código de la aplicación. Las áreas que no son tan importantes para el negocio ( subdominios de soporte o genéricos en la jerga DDD) pueden requerir un enfoque menos sofisticado que el reservado para el núcleo.