In a monolithic codebase without enforced module boundaries, a change to a shared data-model class used by both the billing code path and the reporting code path breaks the reporting module's tests. Why does this kind of ripple effect happen more easily in a monolith than it would across independently deployed services, and what does it cost the team over time?

## Why the coupling happens so easily Tight coupling in a monolith is a direct consequence of the same shared-memory property that makes in-process calls fast: because every class in the codebase lives in the same compiled artifact, any class can, technically, reference any other class directly — there is no structural barrier requiring billing and reporting to interact through a deliberate, stable interface. In the scenario described, reporting most likely didn't import a designed public API from billing; it imported billing's actual internal entity or data-transfer class, because that class was sitting right there, public, and convenient. That's an easy, natural thing to do in a monolith and often goes unnoticed for a long time because it compiles cleanly and works. ## The compiler is the mechanism, working as intended The mechanism that turns this into a ripple effect is the compiler itself, working exactly as intended: when billing changes a field name, a method signature, or a class structure on that shared entity for its own internal reasons, the compiler correctly identifies every single caller across the entire codebase that now fails to type-check or whose tests now fail — including reporting, which had no involvement in and no advance notice of billing's change. This is the coupling made visible. It's not a bug in the compiler; it's the accurate discovery that reporting's correctness was, all along, silently dependent on the exact internal shape of a class it doesn't own. ## Why two deployed services behave differently This differs fundamentally from two independently deployed services. There, the only thing one service can depend on is whatever the other service intentionally exposes: - a REST endpoint; - a message schema; - a published client library. That exposed contract is the one thing the owning team commits to keeping stable (often with explicit versioning, like `/v1/` and `/v2/` endpoints existing side by side during a migration). The service's internal data model can be refactored completely, every day, and no other service even notices, because the network boundary enforces that only the contract is visible from outside. The absence of that enforced boundary is precisely why a monolith needs discipline to recreate, voluntarily, what a distributed system gets automatically from the network: - code review conventions; - module-visibility rules; - or automated architecture tests. ## Why the trade-off runs the other way at small scale The reason this problem exists at all is that the trade-off runs the other way for good reason at small scale: shared, freely reachable classes make small monoliths fast to write, since there's no ceremony required to reuse a well-written class elsewhere. The failure mode only becomes expensive as the codebase and the number of independent teams touching it both grow — the same forces that erode any large shared-memory system without imposed structure. ## How the cost compounds The cost compounds in predictable, observable ways in production and in team velocity. 1. **First, blast radius on change grows.** A class used in three places is a minor refactor risk; the same class used in forty places across code owned by six different teams turns any change into a cross-team coordination exercise, and teams learn to simply avoid touching shared classes rather than improve them, leading to duplicated near-copies of the same logic instead ('I'll just make my own version rather than risk breaking billing'). 2. **Second, test suite fragility increases.** A change intended to affect one feature causes unrelated test failures elsewhere, teams start ignoring red builds because failures are 'probably unrelated,' and genuine regressions get missed in the noise. 3. **Third, onboarding and cognitive load rise.** A new engineer trying to safely change billing's entity class has to first discover every other module that depends on it, because there's no compiler-enforced boundary telling them 'these are the only sanctioned callers.' This is the classic trajectory toward what's commonly called a 'big ball of mud' — a system where the dependency graph between classes has become so dense and undocumented that no single engineer, or even team, can predict the full consequences of a local change. ## The mitigation that keeps the deployment model A well-known concrete mitigation, without abandoning the monolith's deployment model, is the **modular monolith** pattern: the codebase stays one deployable artifact, but module boundaries are made explicit and enforced by tooling — for example, Spring Modulith or ArchUnit rules that fail the build if reporting imports a class from billing's internal package rather than its designated public API package. This recreates the discipline a network boundary would impose, at compile time instead of at runtime, while keeping the shared-memory performance and transactional benefits intact. It doesn't eliminate the possibility of coupling, but it makes accidental coupling like the billing/reporting scenario a build failure instead of a silent landmine discovered weeks later.