Recognise the advantages of what you already have
- Easy visibility of the entire system and codebase for all teams, including faster visibility of other teams' changes.
- A codebase optimised for minimal duplication and maximum code reuse
- Simple, minimal dependency management.
- No need to manage and juggle separate versions of microservices - just a single centralised version
- Atomic changes into a single codebase, and no need to manage the synchronisation of changes into multiple projects/repositories/services.
These are important strategic advantages to the business because they are all factors in keeping down the total cost of ownership of the system, so they need to be included in any cost calculation because losing them will generally add some additional time, cost and risk.
How can we decompose a single pipeline within a single bounded context into multiple services to gain the scaling and organizational benefits, without introducing tight coupling [...]?
Generally there is no way which does not involve either a fundamental rethink of your single Bounded Context(BC) such as defining new smaller BCs, or widespread violations of the D.R.Y. Principle.
Bounded Contexts aren't architecture
Remember that bounded contexts aren't a technical concept but a natural reflection of your domain - a boundary which encompasses all the knowledge relating to some particular aspect of your domain and serves as the authoritative source defining that knowledge. (Knowledge being the sum of all of behaviours, relationships, information and interactions within the BC).
To split into services implies creating barriers between fragments of knowledge which naturally belong together; breaking relationships, adding complexity to interactions, altering behaviours, reorganising information. These aren't just issues for the code or architecture but the underlying requirements, which then impacts how you measure and test your solution.
Splitting a Bounded Context is creating new Bounded Contexts
To split a Bounded Context you need to fall back all the way back to its origins and fundamentally re-examine all of the assertions which led to it being defined in the first place. Otherwise, even if you manage to split your codebase into services, your requirements have not changed, nor has the knowledge it needs to represent; so any change in one part should be expected to impact every other part unless you rethink the model which everything is built upon.
Splitting a codebase without a more fundamental rethink cannot possibly result in meaningfully independent services or projects - you can only get independence by defining new Bounded Contexts (a fact which would likely become all too clear as soon as you consider integration testing, release cycles and deployment).
At which point, consider warnings from history - fundamentally rethinking your domain model is not impossible, but must be done with extreme care not to throw away everything you already have, which as Joel Spolsky described in 2004, is "the single worst strategic mistake that any software company can make"