abstraction == insurance – don’t build layered architectures if you don’t need them
In 99% of cases you do not change from X to Y (SQL,DBMS,UI,Transport,Transaction layer, …). You have some data access and UI, and those are set in stone. If you need to change one of these, you need to majorly refactor / rewrite your application anyway.
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.
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.
— why-you-should-not-implement-layered-architectures