A new benefits domain service must use data from a noisy legacy eligibility system without absorbing that system’s tangled model. Which boundary pattern helps?
Select an answer to reveal the explanation.
Short Explanation
Don’t let the old attic junk become the floor plan of the new house. An anti-corruption layer translates legacy noise so the new domain keeps a clean model.
Full Explanation
A new benefits domain service that must consume a noisy legacy eligibility system should introduce an anti-corruption layer that translates and filters legacy models at the boundary. That pattern keeps the new domain’s ubiquitous language clean and prevents legacy naming, null habits, and incidental structures from polluting modern civic services that residents depend on. Embedding the legacy schema verbatim as the new domain’s public model fails by recreating coupling and slowing modernization. Giving every consumer direct SQL into legacy tables with no translation fails by spreading schema corruption, credential sprawl, and change fragility. Forcing the legacy system to freeze forever with zero adapters fails as unrealistic and still leaves consumers coupled to the old model without a protective boundary. Exam caveat: an anti-corruption layer adds translation cost and must itself be owned, versioned, and tested; it is not an excuse to ignore eventual legacy remediation, but it protects new domains during coexistence. Operational check: define the new domain model, implement a translating adapter with tests against known legacy quirks, forbid direct legacy SQL from the new service, document intentionally dropped or normalized fields, and review adapter defects alongside eligibility incidents.