Trabajando en el modelado de una aplicación basado en casos de uso y modelo entregado por el cliente, uno suele notar algunas cosas, que sin querer y sin ser “experto” en el modelo de negocio puede darse cuenta que simplemente no estan bien.
Me topo con un “simple” sistema de registro, a simple vista parecería ser simple, pero tiene una sutileza, según lo explica el cliente
- Existe una data “común” y “básica” para todos (cosas como nombre, edad, sexo, etc..)
- Si el usuario es tipo “A” entonces debemos preguntar cierta data extra
- Si el usuario es tipo “B” debemos preguntar entonces esta otra data
- Si el usuario es tipo “C” entonces preguntamos esta otra cosa…. y así sucesivamente.
Cuando se modela esto uno piensa correctamente en cosas como herencia y polimorfismo, y si el lector pensó también en esto, esta totalmente en lo correcto. Lo que me llama la atención erea que en toda la data “extra” habían ciertas preguntas como:
- Deporte, Lugar, Hobbie favoritos
- Le gusta X, Y ó Z?
Como esto se repite en “TODOS” los casos, lo más obvio sería agregarlo en la clase base verdad? ERROR!
Luego de analizar un poco más el problema me topo con dos inconvenientes:
- Los objetos “base” o “abstractos” pasan a ser mega objetos inmensos, demasiadas propiedades, demasiadas dependencias. Los objetos concretos son sencillos con solo pocas características dentro de cada uno de ellos.
- La data “extra” solicitada no es usada en NINGUN lugar de la lógica de negocio. El cliente necesita tomarla para “futuras estadísticas”.
Lo interesante es que la data extra aunque no es usada y esta contemplada para “futuras estadísticas” esta debe ser OBLIGATORIAS al contestar y registrarse en la aplicación. Esto claramente me recuerda un pensamiento popular entre nosotros:
“Mejor que sobre a que falte”
¿Qué nos quedaba hacer? Simplemente no podemos obviar al cliente y decidir que “conocemos mejor que él” el negocio. No sería (for the sake of the model) crear una clase abstracta llena de muchísimas propiedades, no sería nada producente. Es cuando el recuerdo del libro de Erick Evans llega a mi mente e ilumina ese momento: Bounded Context.
Bounded Context son “mini aplicaciones” o “módulos” que funcionan independientemente, en donde sus entidades de negocio existen por si solas, donde posee sus propios servicios, entities, root aggregates y demás, PERO que interactua con otros “Bounded Contexts” de forma “normal” através de un “Context Map”.
En este caso en específico creo que la solución es simple y sencilla. No contaminar las entidades abstractas base (que en nuestro caso es un root aggregate, lo que lo hace más delicado) y trabajar la data “extra” como otra entidad perteneciente a un Bounded Context aledaño.
¿Qué opinan ustedes?
.Net Framework
ddd, .net, programming