Domain-driven design para sistemas de comercio exterior

Empezar a diseñar una solución de software puede ser desafiante, especialmente cuando el contexto requiere adaptarse a modelos complejos. En este contenido, se explica de manera sencilla cómo elegir la mejor estrategia según los requerimientos y características del problema, utilizando el ejemplo de un sistema de facturación electrónica para comercio exterior en el entorno del Banco Interamericano de Desarrollo.

¿Qué estilos de diseño existen para abordar un problema complejo?

Existen diferentes estilos de diseño de soluciones. Los más comunes son:

• Top down: Comienzas por las interfaces externas.
• Bottom up: Inicias por el modelo de datos.
• Domain-driven design: El eje principal es el modelo de dominio, especialmente útil cuando trabajas con superdominios y adaptaciones específicas.

Para el caso del Banco Interamericano de Desarrollo, domain-driven design resulta adecuado porque el objetivo es adaptar el modelo OMA a un subconjunto de funcionalidades de comercio exterior.

¿Por qué utilizar domain-driven design en soluciones de comercio exterior?

El domain-driven design ofrece ventajas en proyectos que requieren dar forma a soluciones a partir de un modelo base. Algunas ventajas directas en este caso son:

• Te proporcionan un superdominio (OMA) listo para adaptar.
• La solución se centra en un subconjunto de funcionalidades concretas.
• Desde el inicio puedes estructurar el modelo sin perderte en complejidades excesivas gracias a la posibilidad de crear un modelo sobresimplificado como punto de partida.

¿Cómo representar un modelo de dominio en proyectos con requisitos definidos?

Entre las alternativas para expresar modelos de dominio, el diagrama de clases UML es una opción clara y visual. Allí se centra la atención en:

• Identificar el concepto principal, como el archivo de facturación electrónica de comercio exterior que se envía por aduana de exportación.
• Reconocer relaciones y cardinalidades entre las entidades.
• Entender cómo entidades como el importador pueden ser modelos de dominio independientes, con acciones específicas sobre distintos documentos.

Así, el modelo simplificado ayuda a navegar sobre conceptos clave y relaciones. Esto permite a arquitectos y desarrolladores comprender los casos de uso y planear pruebas basadas en estos conceptos.

¿Cuáles son los límites y alcances del modelo de dominio?

El modelo de dominio de la OMA es muy grande (296 entidades y cerca de mil tipos de datos), pero no es necesario modelarlo por completo desde el principio. Es recomendable:

• Evitar modelar todas las posibles entidades al inicio.
• Incluir solo las entidades principales derivadas de los requisitos.
• Agregar atributos y métodos esenciales, pero no todos los detalles del modelo completo.
• Mantener la lógica de negocio cerca de las entidades, evitando entidades anémicas sin comportamiento propio.

¿Qué ventajas ofrece un modelo de dominio bien diseñado?

Tener un modelo de dominio sólido te permite:

• Crear un lenguaje común entre técnicos y no técnicos.
• Adaptarlo a diferentes estilos arquitectónicos, conservando la lógica central del negocio.
• Dar estabilidad, pues las reglas de negocio suelen cambiar lentamente.

En el contexto particular, las normas de comercio exterior tienen baja velocidad de cambio, pero es importante actualizar el modelo continuamente según se descubren o cambian los requisitos.

¿Cómo gestionar adaptadores y restricciones técnicas en este tipo de proyectos?

El proyecto puede requerir adaptadores entre modelos locales y el modelo general, especialmente para responder a la variedad de requisitos en diferentes países. Es importante saber que:

• Se permite una solución basada en traductores de datos como una medida intermedia para el prototipo.
• No es la solución definitiva para largo plazo.
• Esto da una guía sobre cómo debería evolucionar el sistema y las limitaciones en el diseño.

¿Cuáles son los aspectos clave en la arquitectura y capas del sistema?

El modelo de dominio simplificado ayuda a identificar rápidamente los puntos más críticos:

• Interfaces de seguridad, criptografía y gestión de identidad.
• Abstracciones para mecanismos de persistencia.
• Interacciones con sistemas locales de aduanas y tributos.

Tener claro todo esto permite desde el principio proponer un diseño alineado con los requisitos y restricciones conocidos.

¿Cómo se adapta este enfoque a otros contextos y empresas?

En startups u otros tipos de empresas, puede ser difícil identificar todos estos elementos temprano. El diseño suele ser más genérico y flexible, para permitir que la arquitectura evolucione según aparecen nuevos requisitos con el tiempo.

Esto es un proceso continuo de aprendizaje y mejora, similar a especializarse en algún estilo dentro de la natación: comienzas entendiendo el entorno, luego eliges tu enfoque principal y perfeccionas tu técnica durante el avance del proyecto.