Flujo análisis (continuo) en un proyecto
- Centrar conversaciones en identificar comportamientos (behaviours). Intentamos identificar acciones, verbos, flujos, eventos. Viene fenomenal para OOP centrado en casos de uso o para un enfoque DDD y flujos de negocio complicados.
- Centrar conversaciones en identificar comportamientos concurrentes en el sistema. Nos obliga a identificar relaciones entre esos comportamientos y nos ayuda a hacer un diseño escalable y fácilmente implementable mediante servicios independientes que encapsulan estado y que se comunican mediante mensajes (perfecto para implementaciones con Actores, Pipelines, microservicios, etc.)
Como se puede ver estos dos enfoques se centran en las interacciones de los usuarios con nuestro sistema o las acciones del propio sistema (Verbos) y no tanto en las entidades con las que trabaja (Nombres).
Sin embargo el análisis más típico que se suele hacer en OOP (mal entendida por supuesto) se centra en identificar primero las entidades, perdiendo el contexto de las interacciones (mensajes, flujo, reglas, etc...) derivando, no necesariamente, pero si típicamente, en modelos anémicos y pobres.
Conclusión:
Valoramos la identificación de las entidades (Nombres) con las que trabaja nuestro sistema, pero valoramos mucho más la identificación de los comportamientos (Verbos) que definen cómo interactuamos con nuestro sistema y qué tareas facilita.
Recordemos que los clientes NO quieren software/sistemas, quieren facilitar sus tareas o resolver sus problemas.
3 comments:
Hace unos meses estaba participando en una discusion el blog de Sławek Sobótka sobre si DDD es top-down o bottom-up (la conversacion fue en polaco).
El autor argumentaba que DDD es un enfoque bottom-up. Empiezas a definir tu modelo compuesto por los building blocks de DDD y despues piensas como interactuan estos elementos. O sea, primero substantivos, despues verbos.
En mis comentarios di una opinion distinta. Que el modelado de la realidad depende de los casos de uso. Es una simplificacion de la realidad que mediante una accion (caso de uso) nos permite alcanzar un objetivo.
Un ejemplo podria ser calcular el voltaje/amperaje de un resistor. El modelo mas sencillo para este caso es la resistencia del resistor. Estoy obviando otros efectos que me puede presentar el uso de este elemento electronico.
En la discusion alguin dio un contraejemplo de juego de billar. Hay bolas que tienes su masa y posicion, una mesa con ciertas dimensiones y palos. El juego y las reglas es una cosa secundaria. O sea, primero defines los elementos de juego, sus comportamientos basicos y despues los combinas en algo mas complejo, como un juego de snooker.
Mi contraargumento para este enfoque es, que modelando puedes sobremodelar. Por ejemplo, modelando las bolas desciendes a nivel de atomos y sus enlaces y llegando a un nivel de detalle que no te ayude a solucionar tu problema (saber que aplicando una fuerza con un palo, en que posicion va a terminar la bola).
Completamente de acuerdo contigo...
Además el modelo no es un fin en si mismo es simplemente un medio, así que comenzando por las acciones (que es realmente lo que quieres implementar), saldrá el modelo mínimo para implementar el software, pero si se comienza por los nombres, es muy posible que terminemos con un modelo innecesariamente complejo y en el que perdamos de vista las acciones que es realmente por lo que nos pagan :-)
Leyendo el capitulo 10 sobre LSP del libro "Agile Principles, Patterns, and Practices in C#" de Uncle Bob me ha llamado la atención estas frases:
"The Liskov Substitution Principle leads us to a very important conclusion: A model, viewed in isolation, cannot be meaningfully validated. The validity of a model can be expressed only in terms of its clients."
El modelo es valido (o sea cumple LSP) dependiendo de que esperan sus clientes de los comportamientos ofrecidos por el modelo.
Post a Comment