Two years after a DDD-based microservice decomposition, a Pricing service and a Promotions service constantly deploy together, share a hidden 'effective price' concept neither fully owns, and any change to one breaks the other's tests. As the architect asked to fix this, what diagnostic would you run, and how would you decide whether to merge them, redraw their boundary, or introduce a formal translation layer?

## The symptom Two services that always deploy together and whose tests break in lockstep are exhibiting the textbook symptom of a **distributed monolith** — a system that has the operational overhead of microservices (network calls, separate deployments, separate failure domains) without the actual benefit (independent evolution). In DDD terms, this almost always means the bounded-context boundary between the two services was either wrong from the start or has eroded over time as the two services accreted overlapping responsibility around a concept — here, *effective price* — that neither one fully owns. ## The diagnostic: trace the shared concept The diagnostic starts with tracing the shared concept end to end, not with guessing at an architectural fix first. Concretely, list every field, computation, and business rule involving *effective price* in both services: - where is a promotion discount applied; - where is a base price set; - where is tax or currency conversion folded in; - and which of those steps has to happen atomically with which other step for the number shown to a customer to be correct. This tracing exercise (essentially a mini event-storming pass focused on just this concept) usually reveals one of two underlying situations, and the fix differs sharply between them. ## Situation one: one invariant, prematurely split The first situation is that *effective price* is genuinely one aggregate's invariant that got split across two services — for instance, if a price can never be legally displayed without its currently-applicable promotions already applied, and the two computations must always be consistent with each other at the moment of display or checkout, then this was never really two bounded contexts; it's one pricing concept that got prematurely split, likely along an org-chart line (a Pricing team and a Promotions team) rather than a domain seam. The fix here is genuinely to merge the two services back into one, or at minimum to move full ownership of the *effective price* computation into one of them and make the other a thin, non-authoritative consumer via its API — accepting the loss of two independently-deployable services in exchange for restoring a real, enforceable invariant and eliminating the deployment coupling that was really just distributed-transaction pain in disguise. ## Situation two: two concepts that leaked into each other The second situation is that Pricing and Promotions are legitimately separate concepts — a base price genuinely belongs to Pricing, a discount rule genuinely belongs to Promotions — but the code has let them leak into each other's internals without an explicit boundary: - Promotions reaches into Pricing's price fields directly, or - Pricing has grown ad hoc discount-adjustment logic that duplicates what Promotions already does. Here the fix is not merging but re-establishing the boundary properly: give each service its own clean model (Pricing owns `BasePrice`, Promotions owns `DiscountRule`), and introduce an explicit translation/composition point — often a thin *pricing composition* step, either a small dedicated service or a well-defined API contract — that reads from both and computes the customer-facing effective price without either service reaching into the other's internals. This preserves independent deployability for the two underlying concepts while acknowledging that displaying a price is a composition of two contexts' outputs, not a shared piece of either one. ## Choosing between the two paths Choosing between these two paths hinges on one question: does the invariant require atomic, single-transaction enforcement, or can the two pieces tolerate eventual consistency once properly separated? | Which case you are in | Where it points | |---|---| | A promotion must never be able to apply to a stale base price — a hard business rule with legal/financial consequences, e.g. regulated pricing display requirements | That argues for tighter coupling — merge, or make one service authoritative | | A brief window of staleness between a price update and a promotion recalculation is tolerable (most retail use cases) | The boundary can stay split, connected by domain events (`PriceChanged` triggering a promotion re-evaluation) rather than a shared transaction | ## The organizational dimension The organizational dimension matters too, which is why this is a principal-level call rather than a purely technical one: if Pricing and Promotions are owned by two different teams for headcount or reporting reasons unrelated to the domain, merging the services may require merging the teams (or accepting one team as authoritative owner with the other as a contributor), which is a harder conversation than the code change itself — Conway's Law cuts both ways, and a boundary that's wrong in the org chart will keep re-eroding the service boundary no matter how many times it's technically fixed. A concrete real-world parallel is e-commerce systems that eventually consolidate *pricing engine* and *promotions engine* into one owned pricing-and-offers domain specifically because their invariants (what price a customer is legally shown) turned out to require atomic consistency that two independently-evolving services couldn't reliably provide, while still keeping catalog and inventory — genuinely independent concepts — as separate services connected by events.