Conoce el diseño de Software, orientado al modelo de negocio

Muchas veces, cuando los ingenieros ingresamos a un nuevo proyecto u organización, los líderes nos presentan un conjunto de aplicaciones que soportan las necesidades del negocio, pero en realidad por más funcionen, no sabemos si las soluciones que planteamos van en sintonía con el punto de vista del negocio, y es menor la probabilidad de saber cómo se puede proyectar en el tiempo. Escucha nuestro webinar: DevOps, el camino para entregar software de manera más ágil

Para tener un panorama completo, tanto de las aplicaciones como del modelo de negocio, este artículo busca dar un contexto general acerca de Domain Driven Design (DDD) como enfoque de desarrollo de software, así como describir las partes que lo componen, las herramientas, técnicas y prácticas que aporta para lograr un modelo de negocio profundamente relacionado con la implementación de la solución.

DDD se divide en dos grandes partes: estratégica y táctica, cuyo orden de implementación es definido de acuerdo al estado de avance del proyecto que se va a trabajar con este enfoque. Para un proyecto que esté en etapa de definición y análisis, el punto de partida va a ser la parte estratégica, donde se busca un modelo que nos ayude a entender y resolver las necesidades o problemas que se tienen en un dominio de negocio; seguidamente se inicia el proceso táctico donde se eligen los patrones de arquitectura a utilizar para diseñar la solución, al igual que las tecnologías a usar en la solución de cada Sub-dominio modelado.

El otro escenario se presenta cuando tenemos un proyecto que ya tiene algunas de sus implementaciones realizadas. En este caso, se inicia por la parte táctica, refactorizando los componentes para que se cumpla con los principios de desacoplamiento y separación de responsabilidades que impulsa DDD y después se empieza a incluir de a poco la parte estratégica, en búsqueda del modelamiento de los nuevos requerimientos y de las funcionalidades ya existentes. Lee: Tecnologías de código abierto para implementar DevOps

Para la implementación de la etapa estratégica se deben tener en cuenta los siguientes conceptos que conforman una poderosa herramienta que permitirá modelar el problema:

• Domain: es el problema que se busca modelar y solucionar. Equivale a la suma de las interacciones entre el Core-dominio y los Sub-dominios.
  
  
• Ubiquitous language: es la propuesta de crear un lenguaje común entre las personas de negocio, usuario y el equipo de TI.
  
  
• Bounded context: es un área de conocimiento donde todo lo comunicado, usando el lenguaje ubicuo tiene un solo sentido y este puede involucrar uno o más sub-dominios.
  
  
• Core-Domain: es el proceso más importante del negocio, el caso de uso clave de la organización.
  
  
• Sub-domain: corresponde a la separación del dominio en diferentes problemas o requerimientos.
  
  
• Continuous Integration: otro componente importante por definir en esta sección es la estrategia de integración continua, que a grandes rasgos no ayuda a tener un trabajo colaborativo de equipos muy grandes sobre la misma solución.
  
  
•  Context Map: es el resultado final de las relaciones entre los bounded context.

La situación ideal sería cuando un Bounded Context cubre un único Sub-dominio, lo que equivale a “para cada problema una solución”. Sin embargo, esto suele no cumplirse cuando los negocios empiezan a agregar complejidades pequeñas a los sub-dominios y estos relacionan recursos de otro sub-dominio. 

Por ejemplo, el caso donde tenemos usuarios y opiniones de usuarios. Si quiero mostrar la información del perfil de un usuario, en este punto debo empezar a establecer interfaces para que los sub-dominios se comuniquen en torno a una solución común como el perfil del usuario. Te invitamos a leer: 3 razones para implementar DevOps en una empresa que busca ser ágil

La parte táctica corresponde a la fase de implementación de la solución, esta se basa en una serie de aspectos fundamentales descritos a continuación:

• Entities: considerada por muchos, la unidad de medida fundamental en una solución basada en DDD. Las características principales son:
• Perdurables en el tiempo y se configuran con un ID determinado.
• Agnósticas del framework.
• Deben acumular el 95% de la lógica de negocio.
• Value Objects: son objetos que no llegan a ser una entidad, ya que no cuentan con un ID, se distinguen porque son objetos que pueden ser construido o eliminados pero no es común su modificación.
• Services: corresponde al 5% restante de la lógica de negocio pero esta es sensible al cambio en el tiempo.
• Domain Events: los eventos deben dispararse cuando pase algo importante dentro del dominio, ya sea que ninguna o muchas acciones lo están escuchando, cuando termina el proceso disparado se suele notificar al generador del evento.
  
  
• Aggregates: son agrupaciones de entidades relacionadas entre sí para cubrir una necesidad de negocio.
  
  
• Factories: nace de la complejización de un Agregado o una entidad, cuando estas se convierten en grandes procesos se crean las Factoría.

En el diagrama se ven las relaciones con más detalle entre los conceptos de la parte táctica vistos anteriormente.

La etapa técnica se apalanca también en herramientas, patrones y prácticas como:

• Contenerización. 
• Micro-Servicios.
• Test-Driven Development (TDD).
• CQRS, EventDriven etc.
• ApplicationServices.
• CommandHandler.

Esta etapa es fuertemente apalancada por Clean Architecture y los principios SOLID, donde el más marcado es el de inversión de dependencias, donde las capas superiores no deben depender de las capas inferiores. Para esto, se crean abstracciones de las capas y a su vez, estas abstracciones no deben depender de los detalles, si no todo lo contrario.

Comentarios y conclusiones

• El camino para garantizar en gran medida el éxito de un proyecto es: desarrollar código desacoplado y altas coberturas de testeo.
  
  
• Se puede usar la arquitectura Hexagonal y no necesariamente DDD puro, esto de acuerdo al tamaño de proyecto o la organización.
  
  
• DDD mas que un cambio técnico, es un cambio corporativo. De cómo dividir un problema grande en sub-problemas que darle la mejor solución a cada uno de forma que pueda comunicar entre sí las diferentes soluciones.
  
  
• Sumar prácticas como TDD al este enfoque no es ni muy costoso ni muy lento cuando lo haces bien.
  
  
• Los Product Owner tienden a notar una baja de rendimiento del equipo al momento de iniciar el cambio de modelo de implementación pero esto es algo pasajero y la velocidad de desarrollo se recupera rápidamente.
  
  
• La velocidad de un desarrollador no se mide en cuantas lineas de código escribe por minuto, se mide en la cantidad de decisiones que es capaz de tomar, si se tiene un modelo de dominio bien definido esta capacidad de decisión aumenta.
  
  
• Hay que ser algo pragmático al momento de la implementación de un requerimiento, buscando la solución que mejor rendimiento entregue, que tenga un menor costo y genere más dinero a la organización. No se usan metodologías, Frameworks o tecnologías arbitrariamente (Recomendación: Hacer un TradeOff para este tipo de decisiones).
  
  

  Referencias:

• Eric Evans en su publicación de «Domain-Driven Design – Tackling Complexity in the Heart of Software» en 2004.
• Webinar - Domain-Driven Design Tactical Patterns and CI - Carlos Buenosvinos Zamora
• Introducción a Domain Driven Design (DDD): Parte 1
• Domain-Driven Design. Context Maps