Layers, Levels, and DIP

Uncle Bob's Software Craftsmanship Corner
Layers, Levels, and DIP
by Robert C. Martin
February 20, 2004

Summary
It is often said that high level layers should depend on lower level layers. However the Dependency Inversion Principle says that high level policy should not depend upon low level details. What's up with that?

---

As I read through DDD (Domain Driven Design by Eric Evans), I am concerned by the concept of Layers. I know this is an old saw, but I'm beginning to wonder about it.

DDD describes the following layers in this order:

   UI--->App--->Domain--->Infrastructure

DDD also says that "higher" layers should depend on "lower" layers. Indeed, he stresses that when lower layers need to communicate upwards they should use callbacks or Observers. DDD is not the only source for this concept; it's pretty universal.

So what makes UI "higher" than "app"? Isn't it lower because it's a detail? In fact, isn't the highest level layer the domain layer? Certainly it is at the highest level of abstraction.

Perhaps the "highness" of a layer is not related to it's abstraction? Perhaps it's just it's position in the diagram above? If so, what justifies that position? The infrastructure, for example, seems to be at the same level of abstraction as the UI. Both are details. Both are replaceable without changing the nature of the app. Why are they at two different extremes.

Consider the Dependency Inversion Principle. One way to state this principle is that high level policy should not depend on low level detail. Yet the layering principle says that high level layers should depend upon low level layers. Clearly there is a mismatch here. Indeed, in the diagram above *everything* eventually depends upon the infrastructure; which is the the lowest level most detailed module of all. Could we be talking about two different dimensions of level? Could it be that a module is high level in one dimension and low level in another? What are these two dimensions?

These two dimensions are apparent in the work of Steve Mellor and Gregor Kiczales. Both of them have tried to address this problem in different ways. Gregor created the notion of aspects, so that infrastructure could be woven into an application, and could "Depend" on that application instead of the app depending on it. Indeed, AOP is a very interesting mechanism for conforming to DIP. Mellor created "translation" which is really just AOP at a higher level of abstraction. He created the infrastructure independent from the application, and then wrote another program called a translator to bind the two together. In both cases the infrastructure is orthogonal to the rest of the app.

The dilemma of level, and the two solutions, imply that we aren't thinking about this problem correctly. Infrastructure does not seem to be a layer at all. Somehow it is orthogonal to layers. Somehow it is both at a low level and at a high level. It's at a high level because it represents a policy for using the underlying platform. It's at a low level because it's a detail that most of the app wishes it didn't have to know about.

Perhaps the diagram should be drawn like this:

    |UI|--->|APP|--->|DOM|
   /----------------------/
              A
              |
            |INF|

In other words, the UI, APP, and DOM are traditional layers, with the dependencies pointing in the direction of abstraction. (Apparently this means the the greater the abstraction, the lower the level. I still don't understand why that is.) And these layers are somehow independent of the infrastructure, and the infrastructure somehow manages to make itself felt whether through AOP, or Translation, or some other mechanism.

Without AOP, or Translation, we might draw the diagram this way:

    |UI|--->|APP|--->|DOM|
      |       |        |
      V       V        V
   |UIinf| |APPinf| |DOMinf|
   /----------------------/
              A
              |
            |INF|

In other words, each of the layers uses an abstract interface that represents it's infrastructure needs. It does not know what infrastructure it will be using. It simply states it's needs through an abstract interface and expects the infrastructure to implement that interface and supply the required functionality.

Presumably the |INF| module would implement those interfaces with some kind of adapter that would then forward the calls and messages to the infrastructure itself.

Thoughts?