In a city commerce platform, “price” means shelf list price in the catalog team’s model but means amount due after tax and fees in billing. Which decomposition tool should guide where to cut services?
Select an answer to reveal the explanation.
Short Explanation
Bounded context is like different city departments each owning their vocabulary—“price” in catalog is not “price” in billing. Cut where the language stays coherent, and translate at the boundary. A forced global definition becomes a distributed ball of mud.
Full Explanation
When “price” means shelf list price in catalog but amount due after tax and fees in billing, cut services using bounded context and ubiquitous language so each city commerce service owns a coherent model, with translation at the boundary. Forcing one global meaning creates a distributed ball of mud; keeping catalog language inside catalog and translating when billing needs “amount due” preserves clarity. Decomposition follows where the language stays coherent, not where a single table or traffic percentile suggests a cut.
Putting every meaning of price into one global table so all teams share one definition freezes conflicting models into a shared schema and guarantees semantic collisions. Ignoring language differences and splitting only by traffic volume percentiles optimizes for load while mixing meanings inside the same service. Creating one Oracle Database PDB per HTTP route regardless of business language invents a persistence topology rule that does not map to ubiquitous language or bounded context.
Exam caveat: bounded context / ubiquitous language is the 1084 decomposition tool here—not PDB-per-route recipes or traffic-only splits.
Operational check: document catalog’s price versus billing’s price, place an anti-corruption or translation step at the boundary, and confirm neither service writes the other’s meaning into a shared global table.