In my experience, a good strategy to understand deeply a system or a product is:
- Focus the research and conversations on identifying behaviors (actions, verbs, business flows, and events).
- For these behaviors, we should identify the dependencies, concurrency and parallelism requirements (what depends on what? what actions can happen at the same time? what actions don't depend on any other action? what are the sources/inputs for each action? etc).
Understanding the concurrent behaviors, allow us to design the system using small pieces that encapsulate state and communicate using messages. A good match for OOP, Actors, Microservices, etc.
Is easy to see that this strategy try to identify the interactions that the users have with our system and the corresponding actions (verbs). It does not focus on the entities used by the system (names).
However, the most used analysis strategy try to identify the entities first, losing all the context about the behavior (messages, flows, rules, etc). This strategy derives, not necessarily, but typically, on anemic and poor models. This is a common approach for people who have misunderstood OOP/OOA.
I value the process of identifying the entities (names) of a system, but I value more identifying the behaviors (verbs) that define how is used our system and what actions provide to the user.
We should remember that the customer DON'T want software/systems. The software is only a liability, not an asset. The asset is the actions provided to the customer.
- This strategy can be used at different levels... It helps us to identify bounded contexts, domain events, microservices... And at the low level can also help us to see the concurrent behaviors of each application or service. This allows us to design more reactive and concurrent systems.
- Focusing on identifying names first, make very hard to fulfill concurrency, parallelism and scalability requirements.
- In the real world, things happen concurrently.
- Event storming seems to be a good exercise to identify the domain events, the dependencies, and the behaviors.
- Any strategy for the analysis should be used continuously. For me, development is always iterative, I don't see it any other way.