Service Boundary
The line separating what one service owns and is accountable for from what it must ask another service about.
A good boundary encloses data that changes together, is owned by one team, and can be reasoned about without consulting anything on the other side. A bad boundary cuts through a transaction, so that keeping two services consistent requires a distributed protocol nobody wanted to write.
The reliable heuristics: if two services must be deployed together, the boundary is wrong. If a single user action requires a synchronous chain of four services, the boundary is wrong. If two services write to the same table, there is no boundary at all.
Boundaries are the most expensive thing to get wrong and the hardest thing to change later, which is the strongest argument for starting with a modular monolith and extracting once the change patterns are visible.