I see 2 layers, which should fit very well: a technical and a human component. DDD (the book, the theory i.e.) focuses mostly on the technical one but the whole transformation or product can fail if the human component is ignored or not focused enough.
I have some hints and hope to collect together with you a lot of others. The goal would be to have a list at the end which can be used as a guide for how to decide about BC boundaries when both aspects are taken into account. My other goal would be to find out, what can go wrong when the boundaries are wrongly chosen and how high would be the costs?
Question 1 for @Marco or @Kenny: are you moderating?
Question 2: what do you think about a "whiteboard", to visualize this list?
- feature branches: why are they needed? how often they block other features? how often they lead to merge conflicts?
- bugs/broken features: how often are bugs found by other teams as the implementers? How often ends in finger-pointing and how often in offering help? How fast are these issues found? How fast are they be fixed?
- how many people are needed for a release? how many teams? how often are features released? how long is the "check-list" for one release?
- how many teams are needed for an average feature? can they deliver independently (with feature flags maybe?)
- how mature are the domain experts? what about the developers?
- are the teams split by front-end vs back-end?
- are there people interested in the "other side"? How many? can they lead the others, show the way to a full-stack mindset?
- what domain experiences do they have?
- which persons can work well together?
and so on and on :)