驱动开发的思路形成对比，驱动中需要记住两个原则：
四层架构
Eric Evans在《领域驱动设计－软件核心复杂性应对之道》这本书中提出了传统的四层架构模式，在后来演进过程中出现了五层架构和六层架构，，如下图所示：
- User Interface：用户界面层/展示层，负责与用户交互。包含显示信息、解释用户命令等；
- Application：应用层，用来协调用户与各应用以及各应用之间的交互。不包含业务逻辑、不保存业务对象的状态；
- Domain：领域层/模型层，负责表达业务概念，业务状态信息以及业务规则。包含领域模型、领域信息、业务对象的状态。领域层是业务软件的核心；
- Infrastructure：基础设施层，为其他各层提供技术能力。包括为应用层传递消息、为领域层提供持久化机制、为用户界面层绘制屏幕组件等等。基础设施层还能够通过架构框架来支持四个层次间的交互模式。
六边形架构
随着后续的演进，出现了一种改进分层架构的方法，即Robert C. Martin提出的依赖倒置原则(Dependency Inversion Principle，DIP)。它通过改变不同层之间的依赖关系达到改进目的。
- 高层模块不应该依赖于底层模块，两者都应该依赖于抽象
- 抽象不应该依赖于细节，细节应该依赖于抽象
根据该原则的定义，DDD分层架构中的低层组件应该依赖于高层组件提供的接口，即无论高层还是低层都依赖于抽象，整个分层架构好像被推平了，再向其中加入了一些对称性，就出现了一种具有对称性特征的六边形架构风格。六边形架构是Alistair Cockburn在2005年提出的，其本质是倡导不同的客户通过「平等」的方式与系统交互，通过不断的扩展适配器转化成系统API所理解的参数来达到每种特定的输出，而每种特定的输出都有适配器完成相应的转化功能。
聚合：
- 一组具有内聚关系的相关对象的集合；
- – 是一个修改数据的最小原子单元；
- – 聚合通常使用id访问；
- 实体(Entity)：表示具有生命周期并且会在其生命周期中发生改变的东西。含有VO、具有identity的特性，通常具有生命周期的概念 JPA tag @Entity；
- 值对象(Value Object)：表示起描述性作用的并且可以相互替换的概念。类似于pojo，不可变immutable，可在不同模型中传递，Spring tag @value；
- 领域事件(Domain Event)：所有的领域对象的跨聚合变更需要以事件方式进行通知和记录，聚合内的酌情考虑；
- 工厂(Factory)：负责所有对象的生成和组装；
- 领域服务(Domain Service)：纯技术层面的服务，例如日志，或者是跨聚合的编排服务，通常是Spring Component；
- 资源层(Repository)：类似于DAO层，Spring JPA, Hibernate之类 @CRUDRepository；
- 防腐层：并非是系统间的消息传递机制，它的职责更具体的是指将某个模型或者契约中的概念对象及其行为转换到另一个模型或者契约中；
贫血模型VS充血模型
读完上面的两种分层架构方式，可能很多人会有疑问，这些是什么？为什么我之前一直都没听到过这种分法？确实是这样，DDD和面向对象、设计模式等等理论有千丝万缕的联系，如果不熟悉OOA、OOD，那么DDD可能也会理解不了。因为我们大部分从开发生涯开始之初接触的都是「Action层、Service层、Dao层、DB层」这样的MVC分层理论。并且在21中设计模式中，「行为型」的设计模式，我们几乎没有什么机会使用，导致这些问题的原因是J2EE经典分层的开发方式是「贫血模型」。
Martin Fowler(对，就是提出微服务的那位大牛)曾经提出了两种开发方式，即：
- 以「贫血模型」为基础的「事务脚本」的开发方式
以「充血模型」为基础的「领域驱动」的开发方式
贫血模型
贫血模型是指对象只用于在各层之间传输数据使用，只有数据字段和Get/Set方法，没有逻辑在对象中。而「事务脚本」可以理解为业务是由一条条增删改查的SQL组织而成，是面向过程的编程。
充血模型是面向对象设计的本质，一个对象是拥有状态和行为的。将大多数业务逻辑和持久化放在领域对象中，业务逻辑只是完成对业务逻辑的封装、事务、权限、校验等的处理。
举例，用户管理模块大概是这样的两种实现：
// 贫血模型下的实现
public class User{
private Integer id;
private String name;
...
// 省略get/set方法
}
public class UserManager{
public void save(User user){
// 持久化操作....
}
}
// 保存用户的操作可能是这样
userManager.save(user);
// 充血模型下的实现
public class User{
private Integer id;
private String name;
...
// 省略get/set方法
public void save(){
// 持久化操作....
}
}
// 保存用户的操作可能是这样
user.save();
Martin Fowler定义的「贫血模型」是反模式，面对简单的小系统用事务脚本方式开发没问题；稍微大一些的系统使用事务脚本方式会扩大维护成本，业务逻辑、各种状态散布在大量的函数中，哪怕就是要用户对象中增加一个字段，可能都会涉及到几个类的调整......
希望领域对象能够准确地表达出业务意图，但是多数时候，我们所看到的却是充满getter和setter的领域对象，此时的领域对象已经不是领域对象了，反模式的贫血对象了。其实在贫血模型和充血模型模型之外，还有失血模型和胀血模型，但后者两个基本是实际开发中不会去使用，因为走的是两个极端。
总结
本文宏观角度介绍了领域驱动设计，那么微服务和DDD是什么关系呢？其实在2015年的一次演讲中，DDD的提出者Eric Evans表达了对微服务技术的热爱与支持，认为微服务是让DDD落地的好工具。因为DDD和微服务其本质是降低软件项目的复杂性，而DDD是一种设计理念/设计方法，DDD需要有强制性的原则做保障，否则不同的领域对象终究会混在一起。而微服务本身的一些限制，以及大家都能理解微服务的实施前提和首要条件，会在实现上给DDD增加了一些原则限制。DDD和微服务的不一定要同时使用落地，但是如果将DDD和微服务(两个相差十岁的软件设计方法)结合一起，那么Martin Fowler和Eric Evans两位布道师是会很赞同