El dominio es el rey: Arquitectura Hexagonal sin depender del lenguaje
En el desarrollo de sistemas complejos con reglas de negocio críticas, el mayor peligro no es elegir el framework equivocado, sino permitir que la tecnología dicte las reglas del negocio. Muchos desarrolladores dicen "sé usar Spring" o "sé usar Laravel", pero pocos pueden decir "sé modelar dominios complejos independientemente de la herramienta".
La mayoría de sistemas empresariales no terminan acoplados al negocio. Terminan acoplados al framework.
Para demostrar este nivel de desacoplamiento, he iniciado un proyecto que implementa un sistema complejo bajo una Arquitectura Hexagonal estricta utilizando un enfoque políglota: PHP 8.4 y Java 21.
Los Cimientos: Un monorepo políglota
He optado por un monorepo basado en una plantilla de diseño avanzado que permite que dos mundos distintos compartan una misma alma.
- php: Implementación purista con PHP 8.4, evitando la "magia" de los grandes frameworks para mantener el dominio limpio.
- java: Implementación enterprise con Java 21 y Spring Boot, relegando el framework estrictamente a los bordes de la arquitectura.
Esta estructura no es un capricho, es una paridad de comparación. El objetivo es que las reglas de negocio críticas se expresen de forma idéntica en ambos stacks.
Mañana podríamos implementarlo en Python y generar un módulo para Odoo sin hacer ningún cambio en el modelo de negocio.
DDD y el "Núcleo Sagrado"
En este sistema, el Dominio es el núcleo sagrado. Utilizando Domain-Driven Design (DDD), hemos identificado los agregados clave antes de escribir una sola línea de persistencia:
- Entidades principales: Los elementos centrales del modelo de negocio.
- Contextos de operación: Dónde se aplican las reglas del sistema.
- Invariantes Críticas: Aquí es donde vive la complejidad real. Un elemento no puede entrar en un contexto si excede sus restricciones, y ciertos elementos no pueden coexistir por reglas de negocio.
TDD y Contratos Inmutables
No diseñamos el código y luego lo probamos; diseñamos a través de los tests (TDD). Gracias a una dockerización inmediata, ejecutamos suites de PHPUnit y JUnit que validan el comportamiento del dominio de forma aislada.
Para garantizar que ambos backends hablen el mismo idioma, utilizamos Bruno. Estos tests de contrato validan que la API responda exactamente igual, independientemente de si el motor que hay debajo es Java o PHP.
Los Guardianes: Deptrac y ArchUnit
Un arquitecto no solo diseña, sino que hace cumplir el diseño. He integrado herramientas de validación arquitectónica:
- Deptrac (PHP): Vigila que el dominio no se contamine con la infraestructura.
- ArchUnit (Java): Asegura mediante código que las capas respetan la dirección de las dependencias.
Conclusión: El lenguaje es un detalle de implementación
La gran lección de este enfoque es que el lenguaje no es lo importante. Al mantener un dominio puro y desacoplado, este sistema es tan robusto que su lógica podría trasladarse a cualquier tecnología sin tocar las reglas de negocio.
El valor del software no reside en el framework que eliges, sino en las reglas de negocio que proteges.