Re: Layers, Levels, and DIP

From: Robert C. Martin (unclebob_at_objectmentor.com)
Date: 02/23/04 

Date: Sun, 22 Feb 2004 17:29:33 -0600

On Sun, 22 Feb 2004 11:11:51 -0500, "Ionel Munoz"
<ionelmunoz@hotmail.com> wrote:

>> the interfaces relating to application concepts should depend on
>> the interfaces relating to domain concepts, but the domain interfaces
>should
>> not depend on the application interfaces.
>>
>I would rather say that *the implementation* of higher-level abstractions
>(interfaces) should depend on lower-level abstractions (interfaces). But
>even saying so has a problem for me: why the level is still so important for
>us? Perhaps it shouldn't... Horizontal (flattened) hierarchies have proven
>their validity in the real world. Why not thinking about a layer as a
>consumer-provider module? A layer in fact "consumes" some services through
>some interfaces, while exposes what it "provides" through some other
>interfaces it implements. Should the *layer's level* concept be striped away
>then? Is the layer pattern just a more specialized instance of a pipeline or
>a producer-consumer chain? Well, in that case it would no longer be a layer.
>:-) Any thoughts about this?

The concept of level has it's uses. Clearly we don't want any UI
concept to pollute the APP, and we don't want any APP issues polluting
the DOMAIN. The UI should depend on the APP, and the APP should
depend on the Domain. This allows the UI to change without affecting
the APP, and allows the APP to change without affecting the Domain.

There is an ordering to this insulation of change. We want the Domain
to be the most independent. We don't mind that the APP depends on the
domain, since the APP manipulates Domain concepts. We don't mind that
the UI depends on the APP since the UI manipulates APP concepts. So
the ordering of these layers into levels seems appropriate.

However the infrastructure level is problematic. We want the
infrastructure to be able to change without affecting any of the other
layers. This means that it should depend on the UI. But that doesn't
make any sense because *all* the layers make use of the
infrastructure.

Perhaps the infrastructure is not a layer. Perhaps its just a set of
services that the other layers make use of. Perhaps it's orthogonal
to the concept of layers. If so, we can make the other layers
independent of the infrastructure by having those layers declare
interfaces that the infrastructure must implement. We can prevent the
infrastructure from depending on the layers by creating adapters that
bind to those interfaces and translate the calls to the
infrastructure.

Relevant Pages

  • Re: Layers, Levels, and DIP
    ... > concept to pollute the APP, and we don't want any APP issues polluting ... > the ordering of these layers into levels seems appropriate. ... > However the infrastructure level is problematic. ... > interfaces that the infrastructure must implement. ...
    (comp.object)
  • Re: Layers, Levels, and DIP
    ... > the ordering of these layers into levels seems appropriate. ... > Perhaps the infrastructure is not a layer. ... exposed through interfaces -- so the context would be easily replaceable. ... Part of the infrastructure is exposed by this execution context, ...
    (comp.object)
  • Re: Architectural feedback
    ... The skeleton's not too far off of the general picture I've been thinking. ... Just to make sure we're clear, when you mention interfaces, do you mean (I'm ... > for this app? ... >> core app must reside on the client or may be run from the server. ...
    (microsoft.public.dotnet.general)
  • timer queue
    ... Word and then launching another class as an event sink for the app. ... two classes use custom interfaces to communicate. ... The problem comes in the timer callback. ... "this" ptr as a parameter and static cast to p2 in the static timer callback. ...
    (microsoft.public.vc.atl)
  • Re: Layers, Levels, and DIP
    ... >> concerned by the concept of Layers. ... an App could have multiple alternate UIs. ... Is an OS more general, or more specific, than an app? ... the app changes, and the app to remain constant while the UI changes. ...
    (comp.object)