Index
When a small change requires changing several parts of the system, the problem may be in the dependencies between modules. A localized intervention can improve evolution without initiating a complete rewrite.
How to evaluate this decision
Map out which changes cross borders and why. Identify duplicate rules, shared data access, and implicit contracts. Choose a frontier with observable benefit and preserve tests of current behavior. Separating folders or creating new services does not automatically reduce coupling if the same dependencies continue to exist.
Criteria for comparing proposals
- Diagnosis: use recent changes to find dependencies that generate rework.
- Trimming: Define responsibility and contract for a module before moving it.
- Transition: Maintain compatibility and check consumers during the change.
A scenario to discuss with the supplier
Hypothetical example: changing a discount rule requires editing fulfillment, orders and billing. Centralizing the decision and making your contract explicit can be more useful than dividing the system into new services.
What to validate upon delivery
Implement a representative change after the intervention and compare the scope of the changes. Check tests and consumer behavior, without using number of modules as a measure of success.
Prepare the conversation about the project
Bring Quantum9 examples of difficult changes and available architecture. The diagnosis must propose a cut with clear benefit and risk, preserving functionalities that continue to serve the business.
Software architecture · Map the company's priority