Put legacy account lookups behind a contract the replacement can keep
Three HTTP handlers each translate a legacy account row differently. One returns an absent timezone as null, another inserts UTC, and a third exposes an internal migration flag.
- Focused work estimate
- 1h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Compatibility · API boundaries · Characterization testing
Estimated field mix
- API design50%
- System design30%
- Backend20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics
- FacadeApply
Give callers one stable account-read contract while containing legacy row translation and keeping the boundary deliberately narrow.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional B2B scheduling service stores account settings in a legacy module whose database access leaks into HTTP handlers. A replacement must support existing clients and migration by tenant. Build a local modular application, a synthetic two-tenant dataset, and controllable old/new adapters; no baseline repository or fixtures are supplied. Keep the exercise in one application and local database, with no live customer traffic.
Setup prerequisites
- REST contracts
- Tenant authorization
- Transactions
- Dependency injection
Preceding work
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Create a narrow account-read facade with explicit tenant and account identifiers and one documented public response shape.
- Capture the intended null, not-found, and permission behavior before routing the three handlers through it.
- Keep legacy storage columns and migration flags out of the public response while preserving required client fields.
Implementation constraints
- Use the facade to bound a specific compatibility surface; do not add a generic wrapper around every repository method.
Verification to include
- Exercise all three handlers against synthetic missing, configured, and null-timezone accounts and compare their response contracts.
- Request another tenant's account and assert denial with no internal migration metadata in the response.
Deliverables
- Account-read facade and legacy response characterization cases
Rollout and recovery
Move one local handler at a time through the facade and compare response snapshots; revert a handler without changing stored account data.
Value of the work
For the engineer: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change.
For the team: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.