Delete account facade layers that only rename the same call
A timezone field now crosses AccountFacade, AccountGatewayFacade, AccountServiceFacade, and AccountAccessFacade. Three wrappers have one consumer, add no behavior, and make a one-field change touch twelve files.
- Focused work estimate
- 1h 30m + prerequisites
- Priority in the scenario
- Low
- Engineering practice
- Refactoring · Responsibility analysis · Maintainability
Estimated field mix
- System design60%
- Backend40%
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
- FacadeRemove
Remove redundant facade layers with no compatibility or policy responsibility while retaining the one boundary that protects callers from the legacy model.
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
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Trace the timezone read and identify which boundary owns compatibility, policy, authorization, and persistence responsibilities.
- Remove pass-through facades that add no independent responsibility while retaining the public compatibility boundary and storage port.
- The timezone response, authorization behavior, and adapter substitution remain unchanged with fewer forwarding sites to maintain.
Implementation constraints
- Do not replace deleted facades with a dynamic service locator or merge authorization checks into controllers only.
Verification to include
- Run the same response and adapter-substitution cases before and after the simplification.
- Exercise cross-tenant denial and a storage failure through the simplified path; verify neither is swallowed by forwarding code.
Deliverables
- Focused simplification patch and a before/after responsibility map
Rollout and recovery
Land the forwarding cleanup separately from routing changes so a regression can be traced and reverted without changing migration state.
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.