二 为什么需要依赖注入: 解决耦合

二 为什么依赖注入:
面向对象建模面临的问题:
数据边界和行为边界往往不一致
行为往往跨越多个领域对象:
通过类将行为和其紧密耦合的数据封装在一起,多领域对象行为在一对象中中必然会导致别的对象需要向该对象暴漏其内部状态

DDD模式 领域驱动设计（Domain Driven Desing，简称DDD）:
领域驱动设计就是在可扩展性方面: 将复杂多变的业务排除在稳定不变的内核业务之外 : 实现核心业务,利用分层架构抽取复杂业务
松散分层架构中: 允许某层与它的任意下方层发生耦合。
严格分层架构: 某层只能与位于其直接下方的层发生耦合.

    核心业务只为其中一层,其上为用户界面层（User Interface）和应用层（Application Layer），其下是基础设施层（Infrastructure Layer)
  导致两极:
  贫血模型
    若将跨越多个领域对象的行为建模在领域服务中。如果这种做法使用过度，则会导致领域对象变成只提供一堆get方法的哑对象
  充血模型:
   认为方法应该属于领域对象，所有的业务行为被放在领域对象中，随着支持的业务场景变多,导致领域对象而变成上帝类，而且类内部方法的抽象层次很难一致。另外由于行为边界很难恰当，导致对象之间数据访问关系也比较复杂

解决方式 : 引入依赖, DCI模式是DDI补充
依赖设计: 依赖倒置原则DIP（Dependecy-Inversion Principle
抽象：即抽象类或接口，两者是不能够实例化的。
细节：即具体的实现类，实现接口或者继承抽象类所产生的类，两者可以通过关键字new直接被实例化。
高层模块不应该依赖于底层模块，两者都应该依赖于抽象。抽象不应该依赖于细节(实现类)，细节应该依赖于抽象.

依赖倒置原则在Java语言中的表现是：

模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或者抽象类产生的；
接口或抽象类不依赖于实现类；实现类依赖接口或抽象类

更多DCI设计模型