Avoid useless layers: Let each pattern earn its way into your architecture.
The architect in me just loves building solutions that require a healthy dose of layering. There's nothing more fun than walking through an architecture diagram that's loaded with boxes upon boxes of well-defined layers, each with its own role and each with its own clever acronym.
If you're into architecture at all, you're likely to experience this same dynamic. We all want to feel like we're building something that will be the most reliable, distributable, scalable, extensible solution one could possibly imagine. Words like "pluggable," "de-coupled," and "boundary" must flow off our tongues with regularity. Let's face it, most of us live for generality, and architecture gives us a natural vehicle to show off and express this generality.
Of course, while architects were busy assembling their masterpieces, the industry was busy refining and formalizing these concepts as architectural patterns. Much like the Gang of Four patterns (see the StickyNotes for a reference), these patterns brought a real focus and clarity to the architectural concepts we had been building for years. Having official names attached to these concepts gave us all a real sense of comfort. It's almost a form of validation that tells us what we're doing must be right. <?xml:namespace prefix = o /??>
If you've ever popped open any of the books on architecture patterns, you've likely marveled at what a fantastic job the authors do describing the blueprint for good architecture. These books contain pattern upon pattern that collectively cover all the major concepts you might confront when architecting a system.
For some, these books and these patterns have actually become their de facto standard for architecture. Some architects and designers flock to these concepts as if they have found the Holy Grail of architecture. These patterns are treated with a kind of reverence that I've rarely seen in the world of architecture. I imagine there's some architect out there with a blown-up poster of Martin Fowler tacked to his wall.
On the bright side, this phenomenon isn't exactly a bad thing. The concepts that are called out in today's enterprise architecture books are built upon sound techniques that have been leveraged for years, and applying them in your solutions is usually a good idea. At the same time, I've watched architects and designers apply these patterns, and I've observed a few tendencies that trouble me.
One specific problem I've noticed is what I call the "Copperfield Pattern." This pattern is triggered by the combination of a handful of well-written architecture pattern books, a poorly defined set of architecture requirements, a strong desire for layering, and a general need to feel like you're doing something right. These factors all conspire to induce well-meaning architects and designers to closely mimic the full suite of architecture patterns without considering how or if those patterns are appropriate for their solutions. Somehow, the illusion of doing the right thing seems to be enough.
Obviously, doing anything blindly can't be a good idea. Still, it happens. In fact, at one site I found a handful of architects who somehow felt compelled to directly lift and leverage almost every pattern they could find. It was as if the system's architects were being paid by the pattern. Every tier of the application required some set of patterns.
The result was fairly impressive on paper. The path from the client to the database passed through pattern upon pattern, each with its own distinct role and purpose. With a single click, the client could pass through an Application Controller, to a Business Delegate, to a Session Façade, to an Application Service, to an Enterprise Service, to a Data Access Object, to