Five modules in a municipal portal each hard-code a DNA Center hostname, API version, and a pasted JSON body. A controller move becomes a scavenger hunt. What maintainability fix should the design use?
Select an answer to reveal the explanation.
Short Explanation
Hiding the same address on five sticky notes guarantees a wrong one after a move. One client module plus configuration is the maintainability fix. Scattered hostnames and copied payloads turn a controller relocation into a scavenger hunt.
Full Explanation
Maintainability suffers when five municipal modules each hard-code DNA Center hostname, API version, and pasted JSON bodies. Centralize configuration and a single platform client so host, version, auth, and payload templates live in one place. A controller move or version bump then becomes a config and client change, not a scavenger hunt across modules.
Pasting the new hostname into a wiki while leaving modules unchanged fails because documentation is not runtime truth. Duplicating the hostname into more modules fails by increasing drift. Encoding the hostname only in front-end templates fails by putting infrastructure coupling in the wrong tier and leaving back-end modules inconsistent.
Exam caveat: centralization is not a god object—keep a focused client plus config, not one mega-module that owns unrelated UI.
Operational check: change DNA Center base URL in one config source, restart or reload once, and confirm all five former call sites hit the new host without code edits in each module.
Central config should include environment-specific hosts, credentials via secrets manager references, and API version pins. Pasted JSON bodies belong as versioned templates or typed builders inside the client, not as five divergent string literals. Maintainability is measured by how many places change when DNA Center moves, not by how clever each module is in isolation.