A DMV modernization program proposes services named “all database access,” “all UI widgets,” and “all batch jobs.” Which boundary approach better supports independent business change?
Select an answer to reveal the explanation.
Short Explanation
Useful cuts follow the business—like a “checkout” counter that owns its flow—not a basement of “all database access.” Capability-oriented boundaries let a team ship end-to-end. Layer-shaped slices force lockstep releases when a change crosses the stack.
Full Explanation
Boundaries that support independent business change at the DMV slice around a business capability—such as licensing or vehicle registration—owned end-to-end, instead of horizontal technical layers. A capability-oriented service can ship a licensing change without coordinating “all UI,” “all database access,” and “all batch jobs” as separate trains. Ownership follows the business flow citizens care about, not the basement org chart of technical specialties.
Keeping horizontal technical layers so every business feature still coordinates a lockstep release across the stack recreates the monolith’s coordination tax under new names. Merging UI, data, and batch into one platform-core module only reduces repository count while concentrating change risk. Assigning ownership only by programming language team regardless of business capability optimizes for staff skill silos, not for coherent business releases.
Exam caveat: prefer capability boundaries over layer or language boundaries; “platform-core” mega-modules and horizontal slices are common distractors for this decomposition idea.
Operational check: pick a licensing rule change and confirm one capability-aligned team can ship UI, API, and persistence updates for that capability without a cross-layer release train involving unrelated vehicle-registration work.