|
Layers, Levels, and DIP(1)
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?
| 
