ArsTechnica hosts a number of discussions on software development, and arguably none more important than layering.
Understanding one thing at a time is easier than understanding two things that only make sense when used together … Rules of thumb such as “No cyclical dependencies” or “Dependencies must only reach down one level” simply capture the practically achievable limit of the fundamental idea that one thing at a time is easier to understand than two things.
Whilst interfaces and abstractions buy you immunity to change for a given class/component, a layered architecture buys you the flexibility to swap out an entire layer of technology. That’s something that can happen surprisingly frequently in the corporate world – need to replace MFC with Silverlight then with WFP then with HTML5? No problem if your architecture is layered such that none of the business models need to be re-released for the change. Similarly if a game-changing Hadoop solution is rolled out for your data storage – a well layered architecture can remain impervious. But mix up all that logic so that models source data and user interfaces call into low-level analytics – you’ve got a migration nightmare on your hands.
musingstudio 