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?

---

Advertisement

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?

Talk Back!

Have an opinion? Readers have already posted 17 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Robert C. Martin adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Robert C. Martin (Uncle Bob) has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor Inc., a team of experienced consultants who mentor their clients worldwide in the fields of C++, Java, OO, Patterns, UML, Agile Methodologies, and Extreme Programming. In 1995 Robert authored the best-selling book: Designing Object Oriented C++ Applications using the Booch Method, published by Prentice Hall. From 1996 to 1999 he was the editor-in-chief of the C++ Report. In 1997 he was chief editor of the book: Pattern Languages of Program Design 3, published by Addison Wesley. In 1999 he was the editor of "More C++ Gems" published by Cambridge Press. He is co-author, with James Newkirk, of "XP in Practice", Addision Wesley, 2001. In 2002 he wrote the long awaited "Agile Software Development: Principles, Patterns, and Practices", Prentice Hall, 2002. He has published many dozens of articles in various trade journals, and is a regular speaker at international conferences and trade shows.