Bounded Context

1. Find pivotal events - they indicate that some new process starts or ends. For example, it ends process from one bounded context and starts a new in different bounded context. Also, such an event might have different names in different bounded contexts i.e. EmployeePromoted->SeniorityChanged. Pivotal events usually are discovered during event storming session and marked with vertical, yellow straps.
2. Identify a core value - this a place, or a domain event which is the most important for the business. For instance, it ends a business process earning some money. A bounded context should be built around core value to make it happen.
3. Look for autonomous decisions - a good bounded context should not ask another context for permission to proceed. All needed information should be already available inside it.
4. Look for data changed together - in case if one change always triggers others without any time period between (other change happens immediately after first one), both should be placed in the same context
5. Look for data used together - if data from more than one bounded context are always used together, this may mean that those contexts should be merged
6. Follow the business process - count how many bounded contexts are involved through the business process - it is better if single bounded context realizes a single domain. During event storming, we can put horizontal straps between processes.
7. Define responsibilities - try to describe responsibilities of bounded context with a single sentence. If the sentence is short and compact then good, otherwise there might be too many responsibilities
8. Justify integrations - it is worth asking if all integrations are necessary and understand a reason behind them. Too many of them may mean that a bounded context does too much.
9. Ensure a single source of truth - ask yourself if all business details about given feature are available inside single bounded context thus, a single place is asked for them
10. Review conditional requirements - avoid repeating the same condition at the beginning of each process i.e. "if contractor then do X, else do Y" to understand what model should be used.
11. Look for anti requirements - is there any requirement which cross-cuts different models or different business processes
12. Do Event Storming - start with a big picture to find boundaries proposals, pick those from our are and do Process Level Event Storming, if it goes ok (the process doesn't miss anything, isn't too big, there are no new integrations) then try Design Level Event Storming (but the last one is more for solution space)
13. Try 5. Refined Exploration