Es curioso que justo cuando tenía este post en borrador (lleva ahí un tiempo) vi movimiento en twitter. He visto que recientemente se han publicado varios videos que tengo pendiente de ver. Al final el post que tenía pensado lo dividiré en un par de ellos y es muy posible que caiga alguno mas.
Llevo oyendo sobre Domain Driven Design (DDD) desde hace realmente un montón de años, pero nunca he tenido la ocasión de explícitamente aplicarlo. Ya por el 2015 o así me vi algunos videos y algún curso online, pero tampoco llegué a pillar el hype. Y ese run run ha seguido ahí….
Pues bien, a principios del 2022 tuve ocasión de hacer un curso impartido por Codesai y ahí vi la luz.
A pesar de ver la luz, realmente no he llegado a poner en práctica los aprendizajes. Intentamos por nuestra cuenta, un poco haciendo uso de Magic Time pero fallamos miserablemente.
Posteriormente dentro de la casa si tuve la ocasión de ver que en el tema de los subdominios se había hecho un currazo, donde nosotros habíamos fallado…
¿Por qué estoy sacando ahora este tema? Pues porque estoy leyendo un libro que me parece buenísimo, y estoy refrescando el curso de Codesai. El libro en cuestión es Learning Domain-Driven Design de Vlad Khononov, y me está sirviendo para cimentar lo ya visto con Codesai.
Si con lo que pongo a continuación os entran ganas de más, pues ya tenéis una referencia reciente para profundizar…
¿Porque surge DDD?
DDD surge para evitar el BBoM (Big Ball of Mad, término acuñado por by Brian Foote). Los principales problemas de un BBoM son:
- Falta de foco en el dominio
- Falta de un lenguaje común
- Código sin organización
¿Cual era mi problema?
Pues el mismo de mucha gente… No hemos ido a lo importante. Si preguntas a alguien que si sabe de DDD, la mayoría te dirá que sí, lo de los agregados, repositorios y tal…
Y ese es el problema. De hecho Eric Evans reconoce que él es el gran culpable de que la gente haya entendido mal DDD, por poner la parte táctica primero en el libro, cuando lo realmente importante de DDD es la parte estratégica.
Cuando lo he entendido es cuando me ha hecho click la cabeza. Lo realmente importante es trabajar bien el Dominio, definir los Subdominios y luego los llamados Bounded Contexts.
Los patrones tácticos son recomendaciones para implementar ese dominio. Podrías usar otros patrones…
No tengo el libro azul, por lo que no se como trata la parte del dominio, pero el libro de Vlad Khononov lo trata muy bien.
En el momento de escribir esto estoy leyendo un capitulo sobre como aplicar los patrones tácticos en funcion del tipo del dominio aplicando heurísticos. Super interesante. Creo sobre ello va a ir un post futuro.
Diseño Estratégico
¿Y porque es lo importante? Pues porque, como ya he comentado, podrías no usar los patrones tácticos y seguirías haciendo DDD.Evidentemente no haciendo el canelo… Vamos que la calidad no es negociable, pero vamos… podrías no usar agregados, por poner un ejemplo. Podrías por ejemplo usar IDD de Sandro Mancuso.
Dicho esto… ¿Son interesantes los agregados? (que es una de las cosas rarunas así de primeras de DDD) Pues si tu modelo es muy grande diría que sí, pues te ayudan a organizar el código de una manera muy clara.
Veamos así a vuelo rasante algunas cosas del DDD estratégico. Por completar un poco el post, porque lo imporante ya está dicho, que es esta autonota reflexiva sobre DDD.
Lenguaje ubiquo
Es clave usar un lenguaje claro que todo el mundo entienda. Que no haya ambigüedades. Puedes inventarte una palabra. Ejemplo: twit.
Subdominos
El tema de los subdominios es clave. Es vital el definir bien cuales son esos dominios y clasificarlos como core, generic o supporting. ¿Por que? Porque las estratégia como atacarlo cambia radicalmente.
Por ejemplo si un dominio es core, jamás debieras externalizar, mientras que si uno que es supporting pues podrías.
Si un dominio es genérico, lo más interesante es que uses herramientas genéricas que haya en el mercado en lugar de desarrollarlo. Ejemplo: Single Sign On.
Otro tema clave, es el modelo. Un modelo es una representación de la realidad. Por ejemplo, un mapa es un modelo. Un mapa físico es un modelo y un mapa político es otro.
Cada subdominio tendrá su correspondiente modelo, pero ¡ojo! No tiene porqué limitarse a uno solo. Quizás un determinado problema requiere un modelo alternativo que le vaya mejor.
Bounded Context
“Subdomains are discovered and bounded contexts are designed”
Junto con el agregado quizás sea el concepto más vago. El más complicado de entender… Y sin embargo es vital.
Quizás la forma más sencilla de entenderlo es confrontando con los subdominios. Tanto los subdominios como los Bounded Contexts (BC) permiten dividir el dominio pero lo hacen de una manera diferente. Mientras que los subdominios nacen del análisis de cómo funciona el negocio, son más descriptivos, los BC son diseñados, en base a decisiones estratégicas. Permiten dividir el dominio de negocio en entidades más manejables.
Los BC tienen un par de restricciones:
- Tienen un lenguaje ubicuo (solo uno)
- Los gestiona un equipo
Es perfectamente viable tener un sólo BC con todos los subdominios (un monolito). Como perfectamente viable tener un subdominio por BC.
Como los BC se diseñan, hay que decidir cuáles son sus límites. Ante la duda, lo mejor es hacer el BC mas grande, ya que dividir siempre será mas sencillo (recuerda que los límites lógicos ya los habrás establecido).
Limites fisicos
Se refiere a cosas como repositorios de código, artefactos desplegables, etc. Cada BC se debe implementar, evolucionar y versionar independientemente de otros BC.
Cuando un BC contiene varios subdominios el BC establece un límite físico, y entre los diferentes subdominios hay un límite lógico. Para establecer los límites lógicos usaremos características del lenguaje de programación como packages, modules o namespaces.
Límites de propiedad
Un BC es gestionado por un sólo equipo, pero un equipo puede gestionar varios BC.
Event Storming
Lo meto, simplemente por mencionar la técnica, ya que es muy buena para explorar la solución. A la hora de hacer un event storming básicamente tienes dos opciones:
- Empezar por el final: más foco en el valor, se limitan las opciones.
- Empezar por el comienzo: más foco en la exploración
Documentación
Si has aplicado DDD estratégico vas a tener una documentación fantástica de tus sistema, y que va a facilitar los onboardings, ya que tendrás:
- Diagramas de dominio
- Diagramas de Bounded Contexts
- Glosario del lenguaje ubicuo
- Definición de eventos del sistema