Why You Should NOT Implement Layered Architecture
563 views
Skip to first unread message
François Rey
Sep 14, 2014, 4:30:11 AM9/14/14
to clo...@googlegroups.com
Here is a link to an article which makes me think more people are seeing
the light on the java side:
http://java.dzone.com/articles/why-you-should-not-implement
It's a nice illustrative demonstration that might be handy if you're
looking for arguments for those left behind in Javaland/J22E/Spring ;)
My 2 cents: don't believe layering is forbidden either, but know your
trade-offs!
the light on the java side:
http://java.dzone.com/articles/why-you-should-not-implement
It's a nice illustrative demonstration that might be handy if you're
looking for arguments for those left behind in Javaland/J22E/Spring ;)
My 2 cents: don't believe layering is forbidden either, but know your
trade-offs!
edw...@kenworthy.info
Sep 14, 2014, 12:21:24 PM9/14/14
to clo...@googlegroups.com
Looks like a pretty standard rather naif article by someone who knows enough to be dangerous but not enough to actually understand about trade-offs.
And I'm not sure why you think it's even slightly relevant to Clojure: or did you think Clojure eschewed abstractions?
Softaddicts
Sep 14, 2014, 2:01:28 PM9/14/14
to clo...@googlegroups.com
I think this article is partly true, at least in the OO world we know today.
I dealt with a number of OO based commercial softwares in the past 10 years
that used abstractions that were at best annoying, at worse made the internals
obscure up to a point where you wondered if these were added only to insure
some job security to the "experienced" anarchitects that created them.
Their implementations did not do anything to make things clearer either.
Frameworks are also part of the problem. They tend to inflate up to a
point were there initial intent is not even obvious these days.
Remember why Spring came to life ? Look at it today... it tries to be
everything.
These days I stay away from frameworks and I my work life is far more simple.
My personal rule is that if you create or use abstractions not related to
your business model, you should question yourself seriously if you need them.
The "bottom stuff", Clojure current abstractions coupled with a few others,
message queues, configuration management, ... is a toolbox allowing you to
grab the moon. It's more than enough to do a lot of milleage.
Luc P.
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Softaddicts<lprefo...@softaddicts.ca> sent by ibisMail from my ipad!
I dealt with a number of OO based commercial softwares in the past 10 years
that used abstractions that were at best annoying, at worse made the internals
obscure up to a point where you wondered if these were added only to insure
some job security to the "experienced" anarchitects that created them.
Their implementations did not do anything to make things clearer either.
Frameworks are also part of the problem. They tend to inflate up to a
point were there initial intent is not even obvious these days.
Remember why Spring came to life ? Look at it today... it tries to be
everything.
These days I stay away from frameworks and I my work life is far more simple.
My personal rule is that if you create or use abstractions not related to
your business model, you should question yourself seriously if you need them.
The "bottom stuff", Clojure current abstractions coupled with a few others,
message queues, configuration management, ... is a toolbox allowing you to
grab the moon. It's more than enough to do a lot of milleage.
Luc P.
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Softaddicts<lprefo...@softaddicts.ca> sent by ibisMail from my ipad!
Softaddicts
Sep 16, 2014, 4:31:05 AM9/16/14
to clo...@googlegroups.com
I did not imply that OO was absolutely bad. It's what people are doing
with it. It's been a plague for the last 10 years. The rope is long and thick,
more than enough to hang yourself in several reincarnations.
As far as using OO to represent the real world, it's a mistake.
Things are not as straight forward as they look like. Modeling the surface
is most of the time wrong not withstanding the time it can take to model
everything you can see because you did not think about the essential
stuff you will really need to solve the problem at hand.
I saw enough insane models were the business "model"
was so utterly complex that it made any system improvement a Titan
task. Generality gets hit badly in many OO designs.
You can build an 8 mille bridge with Lego bricks but it's not optimal.
There are better ways. We are not ants or termites.
Luc P.
> Relevant? Well it is always nice to find different articles that are
> bashing on the issues that could appear from badly designed OO programs if
> you want to get Clojure into consideration in your organization.
>
> I don't support that OO is bad. It is just complicate to constrain yourself
> from making it overcomplicated because after all they teach us that it
> should be representation of the real world and sometimes the world is scary
> and crazy place...
>
>
>
>
>
> Best regards | Med venlig hilsen,
>
> KALINA TODOROVA
> T: 0045 52 64 93 73
> E: ad...@ki6i.com
>
> Frederikssundsvej 194 2 1
> 2700 Brønshøj
> <http://www.facebook.com/ki6i.kali> <http://dk.linkedin.com/in/ki6i90>
> <https://twitter.com/#%21/ki6i> <http://blog.ki6i.com>
with it. It's been a plague for the last 10 years. The rope is long and thick,
more than enough to hang yourself in several reincarnations.
As far as using OO to represent the real world, it's a mistake.
Things are not as straight forward as they look like. Modeling the surface
is most of the time wrong not withstanding the time it can take to model
everything you can see because you did not think about the essential
stuff you will really need to solve the problem at hand.
I saw enough insane models were the business "model"
was so utterly complex that it made any system improvement a Titan
task. Generality gets hit badly in many OO designs.
You can build an 8 mille bridge with Lego bricks but it's not optimal.
There are better ways. We are not ants or termites.
Luc P.
> Relevant? Well it is always nice to find different articles that are
> bashing on the issues that could appear from badly designed OO programs if
> you want to get Clojure into consideration in your organization.
>
> I don't support that OO is bad. It is just complicate to constrain yourself
> from making it overcomplicated because after all they teach us that it
> should be representation of the real world and sometimes the world is scary
> and crazy place...
>
>
>
>
>
> Best regards | Med venlig hilsen,
>
> KALINA TODOROVA
> T: 0045 52 64 93 73
> E: ad...@ki6i.com
>
> Frederikssundsvej 194 2 1
> 2700 Brønshøj
> <http://www.facebook.com/ki6i.kali> <http://dk.linkedin.com/in/ki6i90>
> <https://twitter.com/#%21/ki6i> <http://blog.ki6i.com>
François Rey
Sep 16, 2014, 7:09:54 AM9/16/14
to clo...@googlegroups.com
On 16/09/14 10:11, Kalina Todorova
wrote:
Relevant? Well it is always nice to find different articles that are bashing on the issues that could appear from badly designed OO programs if you want to get Clojure into consideration in your organization.
That's exactly why I posted the link: it was intended to those
looking for arguments in favor of clojure, or at least in favor of
deconstructing the babel tower that OO and enterprise frameworks
have become.
This article is not really against abstractions, layering, and overall general OO constructs, but about their abuse in the hope of gaining some sort on insurance against hypothetical change.
The guy that wrote it is not totally naive either as he authored JOOQ, a library aimed at making it easier to integrate SQL in java, short-circuiting the ORM approach by providing a fluent SQL API. A kind of sqlkorma in java.
Also I consider such article to be an example of how gradually the functional thinking and practices are penetrating the OO world, that it's not just language features such as immutability and closures that are making it through, but also a mindset in which do-all frameworks and over-layered architectures become smells, and in which the case for clojure becomes easier to make.
This article is not really against abstractions, layering, and overall general OO constructs, but about their abuse in the hope of gaining some sort on insurance against hypothetical change.
The guy that wrote it is not totally naive either as he authored JOOQ, a library aimed at making it easier to integrate SQL in java, short-circuiting the ORM approach by providing a fluent SQL API. A kind of sqlkorma in java.
Also I consider such article to be an example of how gradually the functional thinking and practices are penetrating the OO world, that it's not just language features such as immutability and closures that are making it through, but also a mindset in which do-all frameworks and over-layered architectures become smells, and in which the case for clojure becomes easier to make.
Lukas Eder
Sep 16, 2014, 1:36:26 PM9/16/14
to clo...@googlegroups.com
On Tuesday, September 16, 2014 1:09:54 PM UTC+2, François Rey wrote:
On 16/09/14 10:11, Kalina Todorova wrote:
Relevant? Well it is always nice to find different articles that are bashing on the issues that could appear from badly designed OO programs if you want to get Clojure into consideration in your organization.
The guy that wrote it is not totally naive either [...]
Thanks for the defense ;-)
Also I consider such article to be an example of how gradually the functional thinking and practices are penetrating the OO world, that it's not just language features such as immutability and closures that are making it through, but also a mindset in which do-all frameworks and over-layered architectures become smells, and in which the case for clojure becomes easier to make.
I most certainly hope so. With Java 8, some more functional / transformative aspects have finally reached the Java ecosystem. Erik Meijer could prove a long time ago that an environment like .NET (with languages like VB.NET) can be "upgraded" to pragmatic application of functional programming. This will happen in Java as well.
If you like that line of thought - and I find it very interesting that you correctly derived it from that post! - then you might also appreciate this article here:
Which shows how a fusion of declarative (jOOQ / SQL) and functional (Java 8 Streams) programming can possibly remove the need for much of the intermediary boilerplate that is most commonly called "business logic". Note that the implementation of all of these elements (jOOQ, Streams) is very object-oriented, so perhaps, we will all come to our senses when we merge the various paradigms...?
On a side note: I'm always looking out for new ideas about how to promote this way of thinking on our company blog. So I'll be happily following your discussion.
Cheers,
Lukas
Reply all
Reply to author
Forward
Message has been deleted
0 new messages