在一个软件系统中，谁决定谁？谁依赖谁？谁拥有谁？
其实，归根结底，是个顺序问题：先来的决定、拥有后到的，后到的当然依赖先来的。
从软件结构看，项目起源于需求，终结于主程序。
所以需求决定业务逻辑，业务逻辑实现了需求所规定的功能，是需求的直接体现，所以业务逻辑也称为领域模型。
业务逻辑进一步决定数据访问和UI层，其中数据访问服务于业务数据的持久化；UI层负责业务逻辑和用户的沟通。这两者都是细节。
然后，一切准备完毕后，主程序（或者叫系统入口）一声令下，Begin Work！
然后，依赖关系就是反过来的：
主程序（系统入口）显然依赖系统的所有部分。
数据层和UI层依赖业务逻辑。
业务逻辑在整个系统中谁也不依赖，它依赖于系统外的东西——需求！
看DongBlog的例子：
唯一特殊的就是ASP.Net中的WebSite既是UI又是系统入口（FrontController模式），所以它不仅依赖于业务逻辑、还要依赖于数据访问。
以上的这个依赖关系产生了一个矛盾的地方：业务逻辑一方面决定了数据访问，使得数据访问依赖于业务逻辑，另一方面业务逻辑又需要调用数据访问，岂不是要个环状依赖？怎么办？接口！
在DongBlog系统结构中，Business层拥有两个接口：IEntityDataAccess和IDatabase，分别规定了实体类数据访问的要求和整个数据库的访问要求，借助这两个接口，业务逻辑一方面掌握了数据访问层的生杀大权——让你干什么那就得干什么，另一方面，不需要了解数据访问的实现——知道你能干什么就够了！甚至连数据库是谁实现的都不需要知道！管它谁负责数据持久化，能用就行！
就用一个叫做“微型系统”的软件公司来做比喻：公司三个人，老板B(usiness)，程序员D(ataAccess)和营销U(I)。老板规定了可怜的程序员D的工作（定义并拥有接口），小D别无选择，让加班就加班，让出差就出差（实现），老板从来不问过程，只看结果（不需要知道细节）。U的待遇好一些，老板一半不太管他，只是常常拍着小U的肩膀说：反正咱们公司能干什么你都清楚，我也就不强制规定了（没有接口），你看着办吧。客户满意就是目的，现在不是强调客户体验嘛~~~~
所以有了接口之后，世界就和谐了。
