Designing degrees of freedom of an architecture

In physics there is a term called the degree of freedom. It is best illustrated with geometry. An object that can move only on X axis has one degree of freedom. An object that can move on X and Y axis has two degrees of freedom.

The more parameters describe how object can change, the more degrees of freedom it has.

I like to use this analogy to talk about a software architecture. Because similarly when designing an app you also design what degrees of freedom your app will have.

Designing an architecture is deciding what can be changed and what can’t be changed in the app. Precisely what can be changed easily and what can be changed tediously.

To decide properly you have to understand what parts of the app can change in the future. The decision made at that early stage determines if the code will lift the weight of changes or fail and will have to be rewritten from scratch.

Also, compared to other design concepts it shows significant adventages. It is superior to DRY, decoupling, KISS, separation of concerns, OOP, component based design and functional programming.

It also is in favour of user centric design. Because the UI is far and most the layer that changes often, it should be prioritized as one of the main degrees of freedom.

Since UI changes often, the frontend layer should not be designed as a soldered solution, something that fits better to the backend layer.