¿Qué es la arquitectura centrada en el dominio?

Basado en la presentación de XConf 2020: ¿Qué es la arquitectura centrada en el dominio y por qué lo necesitas en tu negocio? Yerko Aguirre — Javiera Laso

La arquitectura es difícil

Conway establece que los diseños de sistemas son el fiel reflejo de como esta estructurada una organización, si una organización presenta una estructura de silos donde cada equipo esta aislado del resto, el diseño y arquitectura de los sistemas de esa organización van a presentar los mismos síntomas,

Ley de Conway representada en dibujo.

Tipos de arquitectura en el desarrollo ágil

El software por su naturaleza es cambiante, cuando iniciamos en un proyecto ágil algunas veces no vemos o no nos preocupamos por conceptos de arquitectura que siempre están presentes, por lo cual el producto se vuelve difícil de cambiar en el futuro

Ciclo de desarrollo en un equipo ágil.
Representación de distintos tipos de arquitectura.
  • Arquitecturas modulares
  • Micro Kernels
  • Arquitectura orientada a servicios
  • Arquitectura orientada a eventos

Diseño guiado por el dominio

El diseño basado en dominios es un lenguaje y enfoque de software centrado en el diseño de los dominios para modelar problemas complejos. El término fue acuñado por Eric Evans en su libro Domain Driven Design. Consiste en una colección de patrones, principios y prácticas que permiten que los equipos se centren en lo que es fundamental para el éxito del negocio mientras se elabora software que gestiona la complejidad en los espacios técnicos y comerciales.

Adaptación del diseño guiado por el dominio. Fuente: https://github.com/ddd-crew/ddd-starter-modelling-process
  1. Al descubrir podemos llevar iniciativas como el event storming para poder entender los dominios, los contextos y cuales pueden ser divididos para el proceso siguiente.
  2. Al entender los dominios, podemos descomponer en sub dominios, y comenzar a definir nuestros bounded contexts (de los cuales hablaremos después), además
  3. Debemos saber cómo conectar los sub-dominios ya que una arquitectura débilmente acoplada permite a los equipos trabajar en paralelo sin ser bloqueados.
  4. Al tener una estrategia de dominios centrales, podemos tener un lenguaje común entre el negocio y la parte técnica, a modo de definir routemaps e invertir la maniobra de Conway.
  5. Al organizarnos, debemos considerar que la maniobra de Conway no es lo mejor, ya que puede bloquearnos en etapas superiores.
  6. Al definir los roles y responsabilidades logramos que cada bounded context pueda evolucionar de forma óptima.
  7. Utilizar los patrones que mejor se ajusten a tu negocio y comienza a programar !

Lenguaje común entre negocio y tecnología

Es importante mantener un lenguaje común entre los expertos de negocio y expertos de tecnología, para lograr trasladar estos conceptos al código fuente, de forma tal de que nuestro producto de software refleje los conceptos que son hablados comúnmente por el negocio.

Representación del lenguaje ubicuo.

Bounded Context

Los bounded context son el patrón principal en Domain-Driven Design. Un Bounded Context es un espacio delimitado donde un elemento del negocio tiene un significado perfectamente definido.

Bounded context en un e-commerce.
Adaptación del detalle de un ejemplo de bounded context.

Arquitectura por capas v/s orientada al dominio

Representación de distintas arquitecturas, izquierda por capas, derecha orientada al dominio.
Representación de un caso real sobre las diferencias entre arquitectura por capas y centrada en el dominio.

De la teoría a la realidad: Aplicación en proyectos reales

Arquitectura hexagonal en un e-commerce

Ejemplo de una arquitectura hexagonal.
  • Testables
  • Independientes de la UI
  • Independientes de la base de datos
  • Independiente de agentes externos
  • Más tolerantes al cambio
  • Reutilizable
  • Mantenible
Descripción de una promesa de entrega aplicado a un e-commerce
Ejemplo de una arquitectura limpia.
  • UI puede cambiar fácilmente
  • Fácil testeo
  • Reutilizable
  • Mantenible
Representación del resultado de un cambio de framework gracias a la arquitectura limpia.

¿Cómo comenzar en la arquitectura centrada en el dominio?

Desenredando el monolito, es importante ver si podemos pasar de un monolito modular a microservicios, pero no siempre nuestro monolitos están descritos de forma limpia.

Representación de la expectativa de monolito modular a la realidad de una “big ball of mud”.
Representación de un monolito modular de un e-commerce.
Representación de microservicios en un e-commerce.
Ejemplos de los principios para trazar los límites del servicio.
  • Estás prototipando una idea y necesitas llevarla a producción de forma rápida
  • Código existente presente en una sola unidad de despliegue
  • Las personas desarrolladoras de tu equipo tienen experiencia en microservicios y entienden los conceptos de DDD (a veces adoptamos lo que está de moda sin leer los fundamentos, lo que puede llevar a equivocaciones de base que pueden impactar el negocio)
  • Cuando necesitas unidades de despliegue independientes y escalar de forma horizontal

Mantener la arquitectura en el tiempo

Cuando parte el proyecto, todos se sienten a gusto con la arquitectura, pero si recordamos hoy las decisiones que tomamos ayer puede haber algunas diferencias significativas, por eso es importante mantener visibilidad de las decisiones que tomaron en el pasado, que nos ayude a guiar y verificar que la arquitectura no se desvíe a medida que pasa el tiempo. A continuación me gustaría destacar algunas prácticas:

Representación de un modelo C4 aplicado a una bicicleta. Contexto del sistema (ciclista), diagrama del contenedor (bicicleta), diagrama de componentes (zoom a una rueda), código (estructura molecular del caucho).
Ejemplo de un ADR relacionado a la persistencia de la información.
Representación de un test de arquitectura utilizando ArchUnit.
  • Evitar que la definición de arquitectura se desvíe en el tiempo.
  • Fijar lineamientos de arquitectura en el equipo
  • Test automatizados con los acuerdos técnicos a nivel de equipo
Representación de un ciclo completo de pruebas que considera la pirámide de pruebas tradicional junto con las fitness functions.
  • Pruebas de Resilencia: como una prueba podría ejecutar una carga continua en un servicio mientras se implementa una nueva versión de ese servicio en un entorno de pre-producción.
  • Pruebas de Observabilidad: métricas que indican baja conversión o volumen de usuarios utilizando splunk (fitness functions en base a métricas de negocio)
  • Pruebas de Performance: Por ejemplo cuando queremos que una transacción se realice en máximo 10 segundos, la cual es una métrica definida por la experiencia y el negocio
  • Análisis de seguridad: Los típicos de OWASP (como evitar compartir secretos en un deploy a git), pero también que no vaya a existir información sensible en logs, entre otros

¿Por qué necesitas una arquitectura centrada en el dominio en tu negocio?

Luego de toda la información que hemos revisado nos damos cuenta que la maniobra de Conway de por si no es suficiente, sino que debemos crear equipos de productos; a esta forma de trabajo se le llama maniobra inversa de Conway, donde equipos de productos son capaces de manejar la operación completa de ese producto siendo multidisciplinarios, encargados de sus propios roadmaps pero que pueden conversar entre ellos de ser necesario.

Representación de la maniobra inversa de Conway
Libros recomendados y en los que está basado este articulo/presentación.

Engineer on biotechnology and Software developer. Nerd por excelencia y escritora beginner. Bilingüe y ojalá un día logre aprender alemán

Engineer on biotechnology and Software developer. Nerd por excelencia y escritora beginner. Bilingüe y ojalá un día logre aprender alemán