The first business software I wrote professionally – that is, got paid for – was a set of small and similar calculation applications. I wrote these in the pre-Windows era in some version of Turbo Pascal. And no matter how ignorant I still was about good software architecture, these small applications already had a notion of layered architecture. And though the term design pattern wasn’t even coined back then, many people consider layered architecture to be one of them. Personally I think that writing software in a layered architecture is more of a way of life. I wouldn’t know any other way to build business software. Would you?
Why are layered architectures so useful? Well, first and most of all they allow you to distinguish and distribute the responsibilities that your application, your code has to deliver value to the end user. That is, the user interface does not contain components or elements that handle business logic. Business logic resides in a separate layer. A data access layer does not have anything to do with presenting the data, it deals with the database.
And if your thinking this is trivial, please note that there are hordes of developers who still write database connection strings and queries in each web page they develop and who still validate the same business rules in each web page they data is presented. You’re not alone.
Distinguishing and distributing responsibilities – if done correctly and pragmatically – will deliver a number of benefits to your projects:
- Easier to understand. Code will be easier to understand, not only for the developers who wrote it, but also for the poor bastards who have to maintain the code once delivered. Code is just easier to maintain when you know where to find it. Code becomes traceable.
- Easier to write. Have developed applications for over twenty years, I think I’m entitled to say that a day’s work is more fun writing software under architecture. It’s cleaner, more serene.
- Easier to test. Although I personally consider testing software not the most fun, I do think that software that is written under architecture is far more modular. This makes it possible to define independent unit much better, which makes unit testing easier and better. In fact, testability is one of the main motives to define your layered architecture. Design it with testing in mind.
- Easier to extend. Last but not least, having a layered architecture in place will allow you to add new features, or change the current features more easily. Adding a new use case to the system, or extend the business rules on a particular domain object much harder if the process or business logic is spread throughout the code.
Need I say more?
Layered architecture is great but can also lead to a lot of confusion when people use it too literally.
In a lot of cases people think layered architecture means UI on top of Business Logic on top of Data Access on top of the database with all the layers only talking to the layer below. This leads to an architecture where business objects are not persistence ignorant and leads to very inflexible applications.
A better way of looking at things is layers around a center of business or domain objects. You still work with layers but the layers are arranged differently.