Your Bounded Context(s) are whatever makes most sense according to the needs of your stakeholders. If your stakeholders all need the exact same thing, or their needs only vary in trivial ways, then a single Bounded Context for everything could be fine.
To identify your BCs is to understand, as far as realistically possible, what your stakeholders really need, the differences between them, and ideally how that may evolve in future, if possible.
Consider some of the following:
- Who is paying for all of this? (This person/group usually gets the final say on everything, including the overall scope of the project, the core vision, etc.)
- Who are the other stakeholders?
- What are their needs from the system?
- How closely are their needs aligned with each other?
- What priority do they get over other stakeholders, if any?
Remember that needs and therefore variations could derive from many sources:
- Core purpose of the business
- Separate Business functions
- Legal issues (privacy, industry governance, standards compliance, contracts, etc.)
- Geography/Culture (variations due to location/language/social convention/etc.)
- Bespoke demands from customers/clients
- Corporate structure and governance (e.g. collaboration between different people and teams within the business, future restructuring, reassignment of responsibilities between people/teams, etc)
- Partnerships (e.g. collaboration with external/3rd parties)
Stakeholder needs may involve variations on a single concept; it's a judgement call as to whether that single concept is part of a single Bounded Context or whether it should be represented in different ways for multiple Bounded Contexts.
For example, consider a Sales team generating a Customer Order for Warehouse pickers; the extent to which these cross-over will depend a lot on the business operating model.
There are obvious similarities; both will need to know the product is in-stock, and both will need the customer's delivery address, but the teams perform fundamentally different job functions. Simply identifying some overlap is not necessarily enough to be able to know whether you need a single Bounded Context for Order Processing, or separate ones for Sales and Warehousing
The only way you can decide which way to jump is to start conversations with both to understand out how similar or different their needs.
Having stakeholders talking physically in the same meeting (or call) can often reveal whether they could work with a single unified model, or whether they are so far apart that their needs are likely to diverge in wildly different directions.
The Warehouse team may not care how much the customer paid for the order, the Sales team may not care which palette in the warehouse the order needs to be picked from.
If the Warehouse team's idea of a useful Customer Order system and business rules surrounding it are wildly different from those of the Salespeople, then it might be easier to just treat Sales and Warehouse as separate domains, accepting the need for a layer of complexity which handles translation between them.
Yet the one constant is change; the business could decide one day to make the Sales team responsible for picking and shipping orders in the Warehouse; with two separate models that should be OK - the Sales team just need to learn to how the Warehouse model works.
It'd be harder the other way around however; if you had one model and the business then decides to split and move affected people/teams in different directions (or worse, sell/outsource a business function to another company), the developers could suddenly end up needing to fudge competing, contradictory requirements into the model.
For that reason, some might consider it safer in the long-term to lean toward a greater number of smaller Bounded Contexts, but this extra complexity nearly always has additional costs in development, maintenance, testing, architecture, infrastructure, live support, etc.
The bottom line is that you need to fully analyse and understand your requirements and the people who are affected by the systems; Even two different businesses who appear to work in the same domain(s) may arrive at fundamentally different conclusions about how to divide everything.
Whatever you do, you will never be able to predict everything about the future, so don't just rely on DDD for a maintainable design; one day your domain model will probably be wrong, but you won't know that while you're trying to design it.