Re:Paradoxes of Software Architecture (2012)
by ionrock on Tuesday November 04, 2014 @05:49PM
(#8559538)
One thing that is challenging in managing the boundaries is that often times our languages don't prescribe enough layering. We usually have modules, classes / functions and methods to define our boudnaries. The real world dictates we deal with networks, protocols and content types, yet our languages, environments and communities prefer to recommend simplicity at the language level.
I think functional languages have a more healthy appreciation for layering by nature of requiring functions to act on data rather than having mutable data types. I believe if we want to reduce complexity we HAVE to create more layered systems to scope the bounds of our complexity. The problem is many people see this as over-architecting things. With time, a design can evolve such that 10 or 20 layers, as compared to the 3 in MVC we often see, could be manageable with help from our languages and environments (IDE / text editor / etc.).
This is a good pattern (one of many), but it is no silver bullet, either. If you overdo this, you end up with overly defensive programming, where all code is littered with catching theoretical error conditions that will never occur. That hides the actual functionality and makes code really hard to read and to change.
The solution pattern for this is to move checks at the boundary of the module, so that the code inside can make safe assumptions on the data it receives, so it can concentrate on the real functionality.
As the article says, whatever you do, you can overdo. Software architecture is always about balancing and judging conflicting appoaches and goals.