Field notes
Understanding the intention at several levels is of course extremely important, but it is at least as important to understand the context our initiative will sit in. Sub-domains is one way to capture an interesting part of that context.
A common question in this kind of work is whether to focus on the organisation or on the capabilities the organisation has. The ambition is usually that you should organise so as to optimise for your capabilities. But in practice there is usually a gap between the two. Either way, it can be easiest to start by untangling the organisation, to get an initial picture that can then be refined if it turns out that organisation and capabilities diverge.
If the software initiative is for internal use, it is the internal situation that is interesting to investigate and describe.
If, on the other hand, it is a product for other organisations to use, it is probably rather their organisations we want to capture. The catch is of course that they all look different, so we have to find some kind of common denominator for our target group.
Developers often find it hard to "find" sub-domains, while business-oriented people find it fairly easy. A good reason to collaborate. :)
Not all business logic is equally valuable to own yourself. The sub-domain breakdown forces a deliberate choice: which parts of the problem are our competitive advantage, which support it, and which are generic problems the market has already solved for us? That in turn drives where we put our main focus, and what we would rather buy in.
Split the problem into Core, Supporting and Generic sub-domains. Put the focus on Core, buy or adapt Generic.
NB! This is not about what is important. Everything an organisation does is important (otherwise it should not do it). It is important to follow the law, for example, or to pay salaries correctly and on time. But that is hygiene rather than edge. With Sub-domains the picture gets clearer. What is strategic is ultimately a choice, and that decision is owned by the organisation's board.
It can be interesting to look at where the Bounded Contexts end up in relation to the sub-domains.
A Bounded Context that spans two sub-domains suggests that it also spans two Ubiquitous Language areas, and is typically something worth thinking about one more time.