No necesitáis consultoría sobre DDD: Caso Motor de Reservas

Cuando una empresa me contacta para hacer consultoría, monto un Skype para entender mejor las necesidades y la situación en la que se encuentra. Normalmente, hablo con un par de técnicos y/o el CTO que me cuentan sus dificultades. Tengo varias de éstas al mes. Algunas son empresas grandes (50 developers o más) y más pequeñas (menos de 10 developers). Como no me gano la vida haciendo consultoría, soy muy imparcial con lo que necesitan y sobretodo con lo que no necesitan. En sus dificultades, algunos patrones se repiten (miedos, prejuicios, presiones, modas, etc.). Me gustaría resumir cómo fue una de esas video conferencias por si podéis estar en la misma situación.

Conversación

Ellos: Hola Carlos, necesitaríamos formación o consultoría sobre DDD.

Yo: Genial! Contadme un poco sobre el proyecto.

Ellos: Es un sistema de reservas para el sector X que está muy pensado para la venta por un canal. Ahora tenemos que abrirnos a multi canal y tenemos miedo de liarla parda.

Yo: Ya veo, cuantas personas trabajan en el proyecto?

Ellos: En la empresa, 5 developers, pero en este proyecto somos nosotros dos.

Yo: Dos. Ok. Cuántas tablas tenéis en BBDD?

Ellos: Bueno… deben ser unas 20 como mucho.

Yo: Ok. Y cuál es el estado de vuestro código? Tenéis tests? Subís frecuentemente a producción? Tenéis la lógica de negocio en el web controller?

Ellos: El código está bien. Hay tests unitarios, servicios de aplicación desacoplados de Symfony y tenemos Jenkins. Sí que es cierto que nuestras entidades tienen getters y setters y la lógica de negocio está en esos servicios de aplicación. Sabemos que es un modelo anémico pero nos va bien así.

Yo: Guay! Tener un Anemic Domain Model no es un problema cuando es lo que quieres. Con bajas complejidades suele ser lo que funciona mejor. Volviendo a vuestro proyecto, si el código está desacoplado y tenéis test unitarios, con todo el cariño, cuál es el problema?

Ellos: Bueno… es que antes trabajaba con nosotros un talibán de “todo esto” y tenemos miedo de liarla parda.

Yo: Entiendo. Lo primero que os diría es que no os obsesionéis. Hay que separar lo que es poco relevante de lo que puede serlo más. Por ejemplo, en qué carpeta va un fichero no va a ser determinante para el éxito de vuestro proyecto. Pero las implicaciones sobre CRUD vs. Rich Domains podría serlo. Es bueno ser práctico si entiendes los trade-offs de tus decisiones. Lo estáis haciendo bien. Segundo, parece que vuestra aplicación no tiene una complejidad muy grande. Lo de agregar el concepto de multicanal parece un problema de diseño de software normal y corriente. Discutid frente a una pizarra blanca, proponer varias opciones, elegid una e implementadla. Si no os gusta, la cambiáis.

Ellos: Oh! Gracias Carlos. Nos quedamos mucho más tranquilos. Ha sido una charla reveladora. Hay otros productos que tendremos que integrar más adelante e igual la cosa se complica más. Te importaría que te contactáramos entonces?

Yo: Claro, no hay problema. Gracias a vosotros. Mucha suerte y volved a contactar cuando queráis.

Conclusión

Os dejo algunas recomendaciones que a mí me funcionan:

  1. No os dejéis llevar por modas o presiones, podríais meteros en cosas que no necesitáis.
  2. CRUD (como ejemplo de Modelo de Dominio Anémico) funcionan muy bien (ir rápido y pocos bugs) con lógica de negocio sencilla.
  3. El 80% de los problemas de velocidad de desarrollo tienen que ver con código acoplado y no tener tests. Independientemente del estilo arquitectural.
  4. Si entendéis, sois realistas con los pros/cons de cada decisión y los asumís, estáis haciendo bien vuestro trabajo. Os podéis equivocar, pero con tests y código desacoplado debería ser fácil revertir una decisión.

Espero que hay sido útil. Si tenéis dudas o queréis que os eche un cable, podéis enviarme un mail a [email protected].