Abstraction layers in software are what architecture astronauts tell you to do. Instead, however, half of all applications out there would be so easy, fun, and most importantly: productive to implement if you just got rid of all those layers.
Frankly, what do you really need? You need these two:
- Some data access
- Some UI
Because that’s the two things that you inevitably have in most systems. Users, and data. Here’s Kyle Boon’s opinion on possible choices that you may have
Very nice choice, Kyle. Ratpack and jOOQ. You could choose any other APIs, of course. You could even choose to write JDBC directly in JSP. Why not. As long as you don’t go pile up 13 layers of abstraction:
That’s all bollocks, you’re saying? We need layers to abstract away the underlying implementation so we can change it? OK, let’s give this some serious thought. How often do you really change the implementation? Some examples:
- SQL. You hardly change the implementation from Oracle to DB2
- DBMS. You hardly change the model from relational to flat or XML or JSON
- JPA. You hardly switch from Hibernate to EclipseLink
- UI. You simply don’t replace HTML with Swing
- Transport. You just don’t switch from HTTP to SOAP
- Transaction layer. You just don’t substitute JavaEE with Spring, or JDBC transactions
Nope. Your architecture is probably set in stone. And if – by the incredible influence of entropy and fate – you happen to have made the wrong decision in one aspect, about 3 years ago, well you’re in for a major refactoring anyway. If SQL was the wrong choice, well good luck to you migrating everything to MongoDB (which is per se the wrong choice again, so prepare for migrating back). If HTML was the wrong choice, well even more tough luck to you. Likelihood of your layers not really helping you when a concrete incident happens: 95% (because you missed an important detail)
Layers = Insurance
If you’re still thinking about implementing an extremely nice layered architecture, ready to deal with pretty much every situation where you simply switch a complete stack with another, then what you’re really doing is filing a dozen insurance policies. Think about it this way. You can get:
- Legal insurance
- Third party insurance
- Reinsurance
- Business interruption insurance
- Business overhead expense disability insurance
- Key person insurance
- Shipping insurance
- War risk insurance
- Payment protection insurance
- … pick a random category
You can pay and pay and pay in advance for things that probably won’t ever happen to you. Will they? Yeah, they might. But if you buy all that insurance, you pay heavily up front. And let me tell you a secret. IF any incident ever happens, chances are that you:
- Didn’t buy that particular insurance
- Aren’t covered appropriately
- Didn’t read the policy
- Got screwed
And you’re doing exactly that in every application that would otherwise already be finished and would already be adding value to your customer, while you’re still debating if on layer 37 between the business rules and transformation layers, you actually need another abstraction because the rule engine could be switched any time.
Stop doing that
You get the point. If you have infinite amounts of time and money, implement an awesome, huge architecture up front.
Your competitor’s time to market (and fun, on the way) is better than yours. But for a short period of time, you were that close to the perfect, layered architecture!