Some layers are theoretically easier to reuse than others, and reusability could add more or less value, depending on the software you are building. I have never seen a layer being integrally reused in practice, and I’ve rarely heard or read about such a situation—each time rather ends in a not-so-reusable-after-all situation.
Based on my experience, I would strongly suggest not over-aiming at reusability when it is not a precise specification that adds value to your application. Limiting your overengineering endeavors could save you and your employers a lot of time and money. We must not forget that our job is to deliver value.
As a rule of thumb, do what needs to be done, not more, but do it well.
OK, now, let’s look at the drawbacks:
- By splitting your software horizontally into layers, each feature crosses all of the layers. This often leads to cascading changes between layers. For example, if we decide to add a field to our bookstore database, we would need to update the database, the code that accesses it (data layer), the business logic (domain layer), and the user interface (presentation layer). With volatile specs or low-budget projects, this can become painful!
- Implementing a full-stack feature is more challenging for newcomers because it crosses all layers.
- Using layering often leads to or is caused by a separation of responsibilities between the staff. For example, DBAs manage the data layer, backend devs manage the domain layer, and frontend devs manage the presentation layer, leading to coordination and knowledge-sharing issues.
- Since a layer directly depends on the layer under it, dependency injection is impossible without introducing an abstraction layer or referencing lower layers from the presentation layer. For example, if the domain layer depends on the data layer, changing the data layer would require rewriting all of that coupling from the domain to the data.
- Since each layer owns its entities, the more layers you add, the more copies there are of the entities, leading to minor performance loss and a higher maintenance cost. For example, the presentation layer copies a DTO to a domain object. Then, the domain layer copies it to a data object. Finally, the data layer translates it into SQL to persist it into a database (SQL Server, for example). The opposite is also true when reading from the database.
We explore ways to combat some of those drawbacks later.I strongly recommend that you don’t do what we just explored. It is an old, more basic way of doing layering. We are looking at multiple improvements to this layering system in this chapter, so keep reading before jumping to a conclusion. I decided to explore layering from the beginning in case you have to work with that kind of application. Furthermore, studying its chronological evolution, fixing some flaws, and adding options should help you understand the concepts instead of just knowing a single way of doing things. Understanding the patterns is the key to software architecture, not just learning how to apply them.
