Introduccion
Me gustaría hablar sobre la experiencia de aplicar prácticas DDD a un proyecto existente de Ruby on Rails. Inicialmente, teníamos un monolito que fue escrito durante 10 años. La principal dificultad del proyecto estaba en procesos bastante complejos y alta conectividad. No solo logramos descomponer la aplicación en servicios separados, sino que también aumentamos significativamente la legibilidad del código y hacemos que los procesos descritos sean transparentes.
La resolución de problemas dentro del sistema se volvió predecible, dejamos de trabajar con el recuadro negro y, al final, el sistema mismo comenzó a darnos soluciones.
Para facilitar tanto la percepción como la escritura, se presentará una historia sobre los enfoques utilizados en forma de una serie de artículos. Este enfoque no es una "bala de plata", por lo que me gustaría destacar en primer lugar el segmento de proyectos que esta solución puede encajar. Además, hablaré con más detalle sobre la metodología DDD y la implementación de microservicios de este patrón, describiré las posibles combinaciones de los patrones aplicados teniendo en cuenta su implementación, y finalmente daré un ejemplo de una implementación específica de un pequeño servicio.
Report generator
Tesauro es un glosario de términos utilizados para describir un área temática específica.
Todas las definiciones que se presentarán a continuación son correctas en el marco de este artículo. Puede aplicarlos a su área temática si lo describen lo suficientemente bien.
El problema resuelto en el marco de este enfoque.
El enfoque que se describe a continuación tiene una especialización bastante limitada y, sobre todo, tiene como objetivo resolver un problema específico. Sin embargo, esto no excluye el posible interés de especialistas en campos relacionados. Entonces, tenemos la tarea:
Debe reescribir y mantener un proyecto con una lógica empresarial compleja escrita en Ruby on Rails, con recursos suficientes.
Escribamos esta tarea con más detalle.
¿Por qué es necesario reescribir el proyecto?
Creo que cada desarrollador puede responder esta pregunta. Es más difícil de responder para que esta respuesta satisfaga las necesidades de su negocio.
Utilizamos la definición de Negocio , ya que generalmente se acepta, aunque invertiremos en este término un concepto más amplio: una empresa (algo emprendido por un grupo de personas), ocupación (ocupado).
Los negocios son el esfuerzo de una compañía de personas, expresada a través de acciones destinadas a obtener beneficios para una amplia gama de individuos.
Por ejemplo:
- La compañía fabrica un producto para los consumidores o brinda un servicio.
- El laboratorio está desarrollando un nuevo medicamento.
- La escuela se dedica a la formación.
- El archivo de la ciudad proporciona información a los ciudadanos.
- Lera agrada a sus fanáticos con una excelente figura en la red social.
En el caso masivo, un negocio se basa en la idea de obtener ganancias al satisfacer las necesidades de sus clientes. Para aumentar las ganancias, es necesario satisfacer las necesidades reales del cliente con una gran cantidad de soluciones de calidad. Esta idea se describe como el primer principio del manifiesto Ágil, aunque la idea no es nueva. El hecho de que las necesidades subyacen a nuestra sociedad ha sido discutido por muchos filósofos. Por ejemplo, Platón intentó racionalizar las necesidades, crear su clasificación. Es él quien nombra las principales formas de necesidades económicas: comida, ropa, vivienda. "El desafío de los negocios" es satisfacer las necesidades. Y las soluciones aplicadas deberían aumentar la competitividad del negocio.
Competitividad : la ventaja de un negocio sobre otro.
El manifiesto ágil también nos da una pista de que la flexibilidad del proyecto se mejora a través de su excelencia técnica y calidad de diseño.
Considere la cadena de suministro de valores en el ejemplo de un "proyecto web típico"
- t 0 - tenemos una idea.
- t 1 implementamos MVP . Aquí nos desviamos un poco:
Producto viable mínimo de MVP: un producto que tiene las funciones mínimas, pero suficientes para satisfacer a los primeros consumidores. La tarea principal es obtener retroalimentación para la formación de hipótesis para el desarrollo posterior del producto.
El término fue popularizado por Steve Blank y Eric Rees. MVP es una herramienta eficaz para poner a prueba su idea de negocio y responder a la pregunta principal "Despegue, ¿no despegará?"
- t 2 - Volver a la programación. La idea fue exitosa, recibimos comentarios positivos y pudimos satisfacer una gran cantidad de necesidades de los clientes en el momento indicado.
- t 3 - Esta vez, la satisfacción llegó en menor medida. Hemos aumentado el personal.
- t 4 : entregamos incluso menos valores.
- t 5 - Si no comenzamos la refactorización, en este momento el negocio deja de ser competitivo.
¿Por qué está pasando esto? Con el tiempo, nuestro proyecto acumula un alto nivel de entropía debido a su alta conectividad. Supongamos que tenemos una "Compañía Típica" que consiste en un departamento de marketing, análisis, logística, ventas y administración. Por el momento, el proyecto es el siguiente:
Me gustaría hacer una reserva inmediata de que la conectividad no siempre es la causa de la entropía, pero surge si se implementa un sistema con una gran cantidad de procesos comerciales complejos.
La entropía en el código siempre ocurrirá si los procesos de negocios en la compañía no están formados adecuadamente. Lo que puede ser característico de ambas empresas jóvenes, que están al comienzo de su camino, también es característico de las grandes empresas, donde es imposible sistematizar todo de una vez. Este es un proceso natural y no debemos interponernos en su camino, sino aceptarlo y usarlo. Volvamos al primer gráfico y miremos desde el otro lado:
La integral (el área debajo de la línea) será el dinero ganado. La aplicación real (aplicación real) ganará más que el "ideal" (aplicación Academin), al menos hasta el comienzo de la entropía - t 4 . Eso suena bien, y eso es lo que debes hacer.
¿Pero qué hacer en el futuro? Repetir la refactorización hasta el infinito es imposible. En algún momento, el volumen de la base del código alcanzará un nivel tal que será difícil reescribir "todo a la vez". Y tarde o temprano será necesario dividir el proyecto en componentes separados:
Un enfoque para implementar sistemas complejos es DDD:
El diseño impulsado por dominio (DDD) es un enfoque para desarrollar software para la satisfacción integral de las necesidades, al vincular estrechamente la implementación con los principales modelos de negocio que están en proceso de desarrollo constante.
DDD es una serie de prácticas y definiciones que se describirán con más detalle en el próximo artículo. El patrón central de este enfoque es el Contexto acotado , cuya esencia es que cada área temática consta de varios conjuntos de modelos que no deberían comunicarse con el mundo exterior, así como modelos que se utilizan en el mundo exterior junto con otros contextos limitados. Cada contexto limitado tiene una interfaz claramente definida donde decide qué modelos usar en conjunto con otros contextos.
Este patrón se puede implementar a través de un espacio de nombres (espacio de nombres) y a través de microservicios. Utilizaremos ambas implementaciones, según el nivel de conectividad de contexto. Lo que finalmente conduce a la creación de una aplicación descompuesta y segmentada.
Es poco probable que los gráficos anteriores reflejen la imagen real, pero le permiten comparar diferentes enfoques entre ellos.
Proyecto de apoyo
Como parte del apoyo al proyecto, se deben proporcionar varias cosas.
- Entrega de valor : Scrum, Agile, servicio al cliente, entrega continua.
- Reducción de entropía : DDD, microservicio como una de las formas de separar contextos, documentación.
- Calidad del código : diseño a nivel de dominio, TDD, BDD.
- Calidad del producto : pruebas manuales y automatizadas, seguimiento de errores, registro.
- Disponibilidad del producto : Sistemas de duplicación.
- Velocidad del producto : escala horizontal.
- Retención del equipo de desarrollo : sistema de motivación, apertura, honestidad.
Como puede ver, mantener un sistema complejo requiere una gran cantidad de recursos. En primer lugar, personal altamente calificado. Antes de usar esta o aquella tecnología, piense si tiene la oportunidad de brindar su soporte en el nivel correcto.
Debe recordarse que el umbral para ingresar a un sistema complejo es bastante alto, por lo que es importante proporcionar capacitación para el personal. Además, si queremos trabajar sin fallas, no deberíamos tener especialistas "insustituibles" y, por lo tanto, es necesario asegurar la total intercambiabilidad de todos los roles. Si tiene un 'especialista en entrega continua' que sale del equipo, debe reemplazarlo. Si no se puede proporcionar el reemplazo, entonces no vale la pena introducir la pila de tecnología en "producción" sin proporcionar suficiente soporte.
No se trata de especialistas en el mismo nivel. Permitirle tener un DevOps líder y cierto desarrollador para quien este tema es interesante (la llamada "multiclase"). Para él, como para el "segundo violín", es importante comprender dónde y cómo encontrar herramientas para resolver el problema. Para esto, al menos una cuarta parte del volumen total de tareas entrantes relacionadas con la nueva especialidad se le debe distribuir. Estas tareas se llevarán a cabo lentamente, los costos aumentarán, pero en el futuro esto evitará el riesgo de interrupción en el suministro de valores debido a la escasez de personal.
Tales cosas se describen en los requisitos de Scrum, no me gustaría detenerme en ellas. Lo único a lo que me gustaría llamar su atención, para lo que necesita estar preparado, es a los grandes costos que se gastarán en apoyar su proyecto. Si su negocio no está listo para esto, y comenzó a usar muchas herramientas costosas, arruinará el negocio.
Brevemente
- Si necesita implementar MVP , comience con Ruby On Rails.
- Si el MVP despegó y la idea se justificó, realice la primera refactorización, “aligere” sus modelos con servicios, decoradores, elimine la validación y la capa de base de datos de los modelos en preocupaciones separadas. Escribir pruebas, documentación.
- Si no tiene un proyecto tan complejo y puede eliminar la entropía optimizando los modelos, hágalo.
- Si tiene un proyecto lógico y legible, y necesita aumentar su productividad, mientras que puede dividirse, por ejemplo, entre los usuarios, entonces use la escala. Pero no intente dividir el proyecto en servicios por dominio.
- Si tiene un negocio "complejo" y está buscando una herramienta para conectarse (¿por qué no lo ha hecho aún? Las prácticas descritas se originaron en tales soluciones y tienen un rico conjunto de herramientas estándar, que le ahorrará dinero.
- Si su proyecto está en ruby, tiene un equipo de programadores de ruby, el proyecto contiene una lógica empresarial compleja, se está preparando para la carga o ya está cargado, y la entropía ha crecido tanto que es muy, muy difícil de reescribir, entonces debería considerar usar el enfoque DDD y Microservicios.
La próxima vez me gustaría considerar con más detalle la esencia del enfoque DDD y su implementación de microservicios.
Fuentes de inspiración: