I'm not a novice developer by any means, and when I take over other projects because they are difficult to maintain and I'm the only guy to attempt fixing them, I have always known there were something wrong with the design, but I just could not put my finger on it. I surely could not explain it in terms other than 'a gut feeling'.
You idea of Volatile areas as compared to Variable might be the answer, but I'm still don't quite understand the difference. For me, Volatile also means changes. So, if I have a system that performs a function (don't cringe - it seems functional), I see some like reading different data format for input as the Volatile or Variable part of the design. So, we always put that behind an interface. If we did not put it behind an interface, then every time we had a new input format that needs conversion, it would have a ripple effect in the data input part of the system. In terms of your book, maybe my example is not correct.
Could explain the difference between Volatility and Variable a little more?
OK, let's start small – what is the purpose of using properties? To encapsulate the potential change in the business logic or requirements of a piece of data.
Otherwise, when the logic would change, all those that touched the data would have to change.
So the lesson is that when something changes, you better encapsulate it, or you would create dangerous level of coupling. You want to be decoupled from the data.
Does it mean that there is no conditional logic in the rest of the software?
The same is true with architecture. You want to decouple from the possible changes in the requirements, and the only way to do that is to encapsulate the changes in the requirements.
I call that volatility. If you were to use functional decomposition, then when the required functionality changes, your design will have to change, which is exactly the opposite of what I propose.
You must not have a change in the requirements invalidate the architecture.
Does it mean that there is no conditional logic in the rest of the software? Of course not. You still must use if-else, switch, etc. to handle variability in the state or data, but that is not volatility in the requirements.