On the Criteria for Decomposing Systems into Modules suggests we draw boundaries/interfaces where (we think) change is unlikely. Put the parts we think will change within a module, like implementation details.
This becomes pronunced in unit testing, where the tests add yet another dependency on interfaces, this investment making us more reluctant to change them.
If modules follow organizarionsl structure,
what determines the information flows of organizational structure? And could it perhaps be a good model for code?
Comments
On the Criteria for Decomposing Systems into Modules suggests we draw boundaries/interfaces where (we think) change is unlikely. Put the parts we think will change within a module, like implementation details.
This becomes pronunced in unit testing, where the tests add yet another dependency on interfaces, this investment making us more reluctant to change them.
If modules follow organizarionsl structure, what determines the information flows of organizational structure? And could it perhaps be a good model for code?