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).
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.