Splitting a codebase is easy. Splitting the coupling is the actual work, and it is the part that gets skipped.

The symptoms

• Releases go out in a fixed order, documented in a runbook.
• A schema change requires a meeting with three teams.
• Integration environments exist because nothing can be tested alone.

Each of these says the same thing: the boundaries were drawn around nouns in the codebase rather than around reasons to change.

Services should be separated by what changes together, not by what sounds like a separate thing.

What helps

Draw the boundary where the business capability is, not where the database table is. Give each service its own data and let it be wrong for a moment rather than synchronously correct forever. And be honest about whether the organisation actually needs independent deployability, because if it does not, a well-structured monolith will beat this every time.