A system starts with clear boundaries: a gateway, a few services, a data tier, a vendor integration, an event layer. Eighteen months of delivery pressure later, it has the same boxes and different lines.
Erosion is rarely one bad decision. It is a service that reads another service's tables because that was faster. It is a vendor SDK that reaches into core logic. It is an event that quietly picked up a second meaning.
In a regulated product the cost lands in places that are easy to miss. Classification, verification scope and change control all assume the boundaries on the diagram still exist. When they don't, the documents and the system have drifted apart.
Defend them with structure
- Separate deployable units, so a boundary is something a build can see.
- Explicit interfaces with contract tests on both sides.
- A review question on every change: does this cross a line?
- An architecture description that is checked against the repository, not only written at launch.
Boundaries don't slow you down. Losing them does.
Seen this differently?
Questions, corrections and counterexamples are welcome.
