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.
https://twitter.com/kyleboon/status/506606538505854976
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!
| Reference: | Why You Should NOT Implement Layered Architecture from our JCG partner Lukas Eder at the JAVA, SQL, AND JOOQ blog. |
Well… yeh. Just leave this >30 year-thingy of nonsense called “software-architecture” behind and write everything procedural in one class!
Yay! Not…
Sry, but this article is so polemic, leaving out very many circumstances where architecture just matters… Yes, jOOQ is very nice. And yes, small and clean architectures are the best, and yes, you’re not migrating something 95%…
But the solution should just not be “okay, remove this whole layers, its bullshit”… thats polemic.
This article is about not designing for 30 layers up-front. People default to too many initial layers. It isn’t really about removing layers or not having layers at all (even if the title indicates so)
Yep, that’s called YAGNI and KISS. Nothing to see here.
… but yes, it is a polemic article. Polemics get discussions going :-)
I have found in the long run that, using your approach, while you may have been first to market, the ability to maintain your application with no layers means that areas of concerns are mixed, when one makes a change in one area, it breaks another therefore taking more time and effort by the developers to fix bugs which distracts from adding new features and makes it more difficult to add new features and your codebase becomes unmaintainable and you wind up with a piece of junk.
This article has come across a bit wrong already in the original blog, as well as on Reddit. The point is often that layers designed *up-front* are overengineered. Layers factored out *later on* can be quite reasonable, as they respond to actual needs, not to projected issues.
I understand, now what you are talking about. However, software still should be designed with separation of concerns in mind. I have too often been told to “Just develop, we’ll think about that later.” Only to find that they will say “You have it working, now. Why do you want to refactor your code?” After the maintenance bill comes in, the client drops you.
By no means this post should encourage people to stop thinking prior to coding ;-) But often, what can really be done and abstracted via a simple API is done via a complete architecture layer, which is often the wrong choice.
> SQL. You hardly change the implementation from Oracle to DB2 Done that – a migration Oracle -> postgres because the customer didn’t want to pay the license. Also, There are many products that support multiple databases. > DBMS. You hardly change the model from relational to flat or XML or JSON Done that. True it was a POC, not a real project, but it was still nice to have one layer to go to, and not to touch the whole codebase. > JPA. You hardly switch from Hibernate to EclipseLink True. Not sure about the other direction though :-).… Read more »
Hi,
I fully agree with the author.
Yes, there are times, actual requirements need layered architecture. No denying about it. But more often, some architects know a layered architecture solution before they even understand the problem. All they do is defining the problem with projected issues to suit to the layered architecture solution.
Regards.
That’s exactly how this article was meant
At least this blogger is upfront about being deliberately provocative. Unlike the OOP fanatic from a few days ago.
Which one was that?
http://www.javacodegeeks.com/2014/09/oop-alternative-to-utility-classes.html
I’m kind of with you as far as giving such topics a good thinking over. I went thru these same discussions/arguments (mostly with myself) when learning to think in terms of Java (OOPish) as opposed to C, Fortran, etc. (I’m old, what can I say, heh).
Hah, yes. I’ve read that article on the original blog and tried my luck challenging the opinions of the author (without success, obviously): http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html#comment-1370603823 But I don’t take these things too seriously. At least not as long as I don’t have a co-worker who is actually that dogmatic. And as you said, the point of this article here is to give these topics a good thinking over. The only reason for it to have been black-whitish was to trigger discussion. The “middle way” is obviously the best one (as always), but it would’ve been a boring read. Now, you should… Read more »
The Fortran days weren’t better, they were simpler. Take UI API platforms for instance. I remember sitting in on a Motif (Unixish desktop GUI platform) talk circa late 80’s or was it early 90’s and thinking to myself. This is such a lot of code and trouble to put this little clicky box up on screen. Callbacks? OOP? Tons of little code snippets just to get some basic interaction with the user. Who would use such a thing? The cost of development would be incredible! And so karma, poetic justice, or the Fates must have heard me because I found… Read more »
So, what if you actually want to unit test your code?
Abstraction layers (interfaces) can often make unit testing easier, as you can stub out a dummy/test implementation. I know some of that can be done with mocking frameworks, but that’s not always as easy, IMO.
Yes, layers provide the easiest API for tests. Much like too many layers, you can also have too much layer-testing, though. But there’s nothing wrong with having a clean API towards the UI, which can be tested both ways (mocking the UI or mocking the backend)
Ah, another “Why you should/should not ” blog post. My $ .02, FWIW: It is seldom a good idea to deal in absolutes; it is usually better to let the problem statement drive the architecture. I’m not even sure how one would evaluate the correctness of an architecture, absent a context in which to evaluate it. The exact same design can be simultaneously correct and incorrect, depending on the context. Boldly stating that one should NOT implement layered architecture, period, is just not correct. It would have been more useful to describe specific scenarios where a layered architecture does and… Read more »
It in fact doesn’t read like a layered architecture never makes sense. Only the title says that
Anything over 3 layers in an application is usually over-kill. It is worthwhile to make a distinction between layers in an application, which this article is about and layers between applications. My organisation bought a tool to develop applications for xx million dollars + other licenses. There is a service and facade layer. And even these 2 layers is too complex for some developers who built classes with over a 1000 lines of code with domain logic in the facade layer. There is simply no substitute for professionalism. In most cases it is easier and faster to re-factor an application… Read more »
The choice is between: – putting a lot of effort in a multi-layered application for a rare occasion something may change – versus keeping things simple and re-factor when the need arises In over 40 years software development I have rarely seen an implementation being replaced by another just for technical reasons. All the effort put in building layer upon layer is a waste of time. In the rare case something may require a change , re-factoring is much easier. Similar arguments are used to justify an integration layer in the enterprise. From what I have seen it is a… Read more »
Application architectural layering isn’t (or, shouldn’t be) about be able to switch out random big chunks – that’s a strawman. IMO, architecture is about a structure that lets you focus your attention/skills/tools on the immediate problem, without wading through off-topic cruft … layering is just one technique for helping to keep an application maintainable and extensible by evolving teams, in times of evolving technologies. (Of course, a modern application architecture isn’t so much “layered” as “componentized.” But that’s a different discussion :)