The Maintainability Myth
I often come across projects that are built with a multitude of layers to the application. When asked why, I am often given the following response: “We wanted to have this application be more maintainable and flexible, so we put in layers to keep things separate and pluggable.” Somehow, the architectural goal of maintainability has been mixed up with adding more layers (we’ll talk about flexibility in a future post). Here is my definition of the architectural quality of maintainability:
Enabling a system to be repaired or improved without introducing brittleness, commonly through the use of low coupling, modularity, and documentation
No where in this definition do you see a requirement to introduce layers in an application to achieve this. Unfortunately, this is often times what designers and architects do. So, let’s take a look at 2 valid architectures for a JEE application. The first one the most layers and is what started me on this rant (click on an image to enlarge):
The second is more simplified:
Which one of these architectures honors our definition of being maintainable through low coupling and modularity? Yep - all of them!
So, if both of them meet our architectural quality goal of being maintainable, which one do we choose? Let’s take a look again at our diagram with the most layers and consider some things:
- Does our delegate layer add value to the action components, or should the actions call the services directly? Another way to ask this: do our actions and services require any less coupling than they already have? Not really, since our rich client doesn’t really need it our actions probably don’t either
- Does the persistence manager add value to the data access objects, or could the DAOs do that work themselves? Another way to ask this: do our services require any less coupling than they already have with the database? Probably not, since the services define our transactional boundaries and need to be closer to the data for custom queries and bulk loading
- Does our DAO layer add value to our business model that requires separating this code? Another way to ask this: Does our business model/business logic need to be any further away from the database? Probably not, as our business model is driven by the data within the database
It isn’t that more layers equals more maintainability, it is that maintainability is relative to the project. Not all projects need all of these layers to achieve the goal of being maintainable. In fact, the more layers you have, the harder you have to work to test all of the lines of code and APIs you are producing. And, the more factories, configuration, and interfaces you have.
Next time you have to architect a web application, ask yourself if everything that you put into it is adding value, or if it is just getting in the way. Then, when you’ve subtracted all that you can, verify that what you have left achieves your architectural goals.
Technorati Tags: software architecture, architecture quality, layers, maintainability
James @ June 12, 2006