Change is not an exception in software. It is the norm.
The useful question is not whether a design can satisfy the business requirement today. The useful question is can the design satify the next? Does the design make that movement cheap or expensive.
Building for change does not mean abstracting everything. It means being precise about what is volatile. Put seams around behavior that is likely to change over time. Avoid turning every possible future into a framework.
The discipline is restraint: enough structure to absorb change, not so much structure that the system becomes an argument with itself.