For me that is about boundaries. Using DDD we can define the boundaries of our stream-aligned/feature-teams in a very clear manner. The follow-up question for me is then: 'Given team X in subdomain Y - is there a piece of the burden that we can transfer to another team without domain 'dilution'?

Example could be to spin up an enabling team that paves the road before them (e.g. on the functional side using a research projects, prototypes, design sprints).

Other example could be to have a team take over part of there technical worries in their stack to a platform team and deliver it as building blocks (e.g. monitoring).

So the fact that DDD makes it clear where a team's boundaries are and how they interact facilitates the follow-up question for me: 'how can we speed them up or enable them better?'. And that answer can help you in aligning your facilitating teams.

Hope this helps.