Layers, Levels, and DIP铪铪
来源:互联网 发布:蒙泰软件免费下载 编辑:程序博客网 时间:2024/05/17 02:38
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--->InfrastructureDDD 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?
- Layers, Levels, and DIP铪铪
- Layers, Levels, and DIP铪铪
- Layers, Levels, and DIP
- Window Layers and Levels
- Window Layers and Levels , Mac OS
- Director, Scenes, and Layers
- View layers and animations
- Network layers and protocols
- H.264 Profiles and Levels
- H.264 Profiles and Levels
- H.264 Profiles and Levels
- Interrupt Request Levels and DPCs
- document.all and document.layers
- LTE CodeWords and Layers and Ports
- Creating Processes: Sessions and Integrity Levels
- Oracle Partner Levels and Diamond Partners List
- Codeforces 674C Levels and Regions
- Compiler optimization levels and the debug view
- GoF的设计模式是Java基础知识和J2EE框架知识之间一座隐性的"桥"
- 源代码就是设计 续篇
- 软件思考系列之一
- 测试观念谈
- Test
- Layers, Levels, and DIP铪铪
- 自底向上设计
- oracle返回update的件数/updateした件数を取得する関数
- 使用mcrypt加/解密【转载】
- Hackers and Painters
- 代码自动生成和抽象
- 权衡的艺术
- 源代码就是设计
- 软件开发的本质 --《敏捷软件开发:原则、模式与实践》