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.
