Comments on: Layering – too simplistic to actually work

By: Arnon Rotem-Gal-Oz

Arnon Rotem-Gal-Oz — Mon, 04 Jun 2007 13:16:50 +0000

@Henke:
If you were doing layered architecture the BL would know how to call the DL but it would have to use the DL objects not the BL – since the BL layer knows about the persistence layer below it but it doesn’t know about the BL – as that would violate the layering.
The BL can use the DL objects but if it has to expose other objects (its own) for other more upper layers to use.
If you are not doing a strict layers more upper layers (e.g. a UI) can see the objects of the DL even though they are not directly below them
You can create an interface for the “entities” if this interface belongs to the DL you are OK , if it belongs to the BL or external to both you can also be OK – but then it is not layers

Which brings us to what Udi said that these “non-layers” are not really useful and don’t say much about the architecture

@Udi
You probably know I agree that the “layer diagrams” (actually block diagrams) you talk about are not *the* architecture. but the fact the a lot of people don’t fully understand a concept and don’t use it correctly doesn’t mean the concept is flawed (just think about SOA )

Arnon

By: thesoftwaresimplist

thesoftwaresimplist — Mon, 04 Jun 2007 08:52:48 +0000

Arnon,

Of course you’re right, my friend. I should have been more specific as to the use of layered architectures for application development.

Henke,

Thanks for backing me up. I need all the help I can get with Arnon

Mark,

I agree with your agreement. I find that the basic principle which guides me is:

http://udidahan.weblogs.us/2007/05/12/first-principle-of-design-refined/

I find that the kind of questions/answer flow I did in the article helps architects and developers shift their thinking from layers to more actionable/workable designs. I have yet to be callled a heretic

By: Mark Seemann

Mark Seemann — Mon, 04 Jun 2007 08:37:29 +0000

I totally agree with this article. It’s getting to the point that I’ve more or less stopped thinking about applications in layers; these days, I just think about good application design as being built on a composable hierachy of isolatable libraries with clear separation of concern.

But when I talk to architects and lead developers about concrete designs, I still talk about layers, because the other thing is still too ‘heretic’

By: henke

henke — Mon, 04 Jun 2007 00:40:02 +0000

Arnon: If I got a data layer and a bll. By your reasoning, the bll and the services within ought to know about how to save stuff to the database. So you’re saying it should have a dependency to the data layer. But then the data layer must know about the object model of bll in order to map to objects, so the data- must add a reference to bll- — creating a circular dependency.

Let the definition of a layer be that it’s agnostic of what’s directly under it, instead, and let it define what’s under itself by the use of interfaces, which in turn can be refactored to a “vertical layer” (not a layer really) which both bll and data uses, to know what they can expect of each other.

Or am I misinterpreting you?

By: Arnon Rotem-Gal-Oz

Arnon Rotem-Gal-Oz — Sun, 03 Jun 2007 23:08:06 +0000

The problem is that when you add a “Vertical layer” all the layers that share that are no longer separate layers.
The defining character for layer is that they only know layers below them (or the layer directly below them if you are strict). Since the entities “layer” invalidated that you didn’t see or get any value from it.
Layers do add complexity if all the layers use the same semantics – since what you do then is essentially translating data between formats (which is why you are tempted to add a “vertical layer” which everybody knows) – Nevertheless, layers work well if you change the semantics when you move from layer to layer. just consider the TCP/IP stack which builds on the layered architectural style

Arnon