In the book sample I've been citing, there's a reference to a 1972 paper titled
On the Criteria To Be Used in Decomposing Systems into Modules by David Parnas. In the conclusion of the paper,
David Parnas wrote:... it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.
What I've read in the book sample and Juval's answers so far does seem to align to the above proposal, to base design decisions on what's likely to change (what Juval refers to as Volatility-based Decomposition).
I'd like to get some feedback on my current understanding, which admittedly is still very fuzzy, about all this. Drawing from what I know and what I've experienced in the past, it seems to me these ideas are related to DRY (Don't Repeat Yourself) and the Single Responsibility Principle (that a software module should have one and only one reason to change). One of the criticisms of functional decomposition is that you often end up duplicating the same kind of functionality or "knowledge" across multiple modules. This is a violation of DRY which states that "In a system, there should be one and only representation of each piece of knowledge."
Juval, am I (even somewhat) on the right track here? There are still a lot of other questions I'd like to ask but it seems to me the above is fundamental to correctly understanding yours and Parnas' ideas about modularization and decomposition.