简介
革新的对象——面向数据库的架构
领域驱动设计(DDD:Domain-Driven Design)提到服务器后端发展三个阶段
- UI+DataBase的两层架构，这种面向数据库的架构没有灵活性。
- UI+Service+DataBase的多层SOA架构，这种服务+表模型的架构易使服务变得囊肿，难于维护拓展，伸缩性能差
- DDD+SOA的事件驱动的CQRS读写分离架构，应付复杂业务逻辑，以聚合模型替代数据表模型，以并发的事件驱动替代串联的消息驱动。真正实现以业务实体为核心的灵活拓展。
领域驱动设计和开发实战不投入资源去建立和开发领域模型，会导致应用架构出现“肥服务层”和“贫血的领域模型”，在这样的架构中
- 外观类（通常是无状态会话 Bean）开始积聚越 来越多的业务逻辑，而领域对象则成为只有 getter 和 setter 方法的数据载体。
- 这种做法还会导致领域特定业务逻辑和规则散布于多个的外观类中（有些 情况下还会出现重复的逻辑）。
- 在大多数情况下，贫血的领域模型没有成本效益；它们不会给公司带来超越其它公司的竞争优势，因为在这种架构里要实现业务需求变更，开发并部署到生产环境中去要花费太长的时间。
基于数据库设计
多视角理解领域驱动
分解复杂性视角
领域驱动设计在互联网业务开发中的实践 解决复杂和大规模软件的武器可以被粗略地归为三类：抽象、分治和知识。
- 分治 把问题空间分割为规模更小且易于处理的若干子问题。分割后的问题需要足够小，以便一个人单枪匹马就能够解决他们；其次，必须考虑如何将分割后的各个部分装配为整体。分割得越合理越易于理解，在装配成整体时，所需跟踪的细节也就越少。
- 抽象 使用抽象能够精简问题空间，而且问题越小越容易理解。举个例子，从北京到上海出差，可以先理解为使用交通工具前往，但不需要一开始就想清楚到底是高铁还是飞机，以及乘坐他们需要注意什么。PS：《原则》中也有类似的表述，你在思考高层次的事情时，一定不要考虑低层次的细节。《重构》中讲一个方法只要 包含跟该方法同级层次的代码。
- 知识 顾名思义，DDD可以认为是知识的一种。DDD提供了这样的知识手段，让我们知道如何抽象出限界上下文以及如何去分治。
西瓜可以横着切也可以纵着切，分治怎么分也要找到一个切口。
在系统复杂之后，我们都需要用分治来拆解问题。一般有两种方式，技术维度和业务维度。技术维度是类似MVC这样，业务维度则是指按业务领域来划分系统。微服务架构更强调从业务维度去做分治来应对系统复杂度，而DDD也是同样的着重业务视角。DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。
领域驱动设计学习输出「DDD」则把大多数的业务逻辑都包含在了「聚合」、「实体」、「值对象」里面，简单理解也就是实现了对象自治，把之前暴露出来的一些业务操作隐藏进了「域」之中。每个不同的区域之间只能通过对外暴露的统一的聚合根来访问，这样就做了收权的操作，这样数据的定义和更改的地方就聚集在了一处，很好的解决了复杂度的问题。
软件架构设计视角
为什么是“领域”驱动，而不是什么别的东西驱动？比如服务驱动？对象驱动？
- 简单的系统数据库CRUD就可以搞定，只有足够复杂且多变（二者缺一不可）的系统才用得上领域驱动
- 开发人员经常把业务流程实现成系统流程，业务流程复杂、多变的时候， 系统流程也必须做出改变，因而需要在“业务流程”和“系统流程”之间提出一层，即领域模型
- 领域就是现实世界的业务，是复杂多变的，我们看到的只是现象。而领域模型就是要找到这些现象背后不变的部分，也就是本质，也就是“变化”背后的“不变性”
- 就像任何一门语言，最基本的是单词。领域驱动设计的一系列概念：实体、值对象、聚合根、领域事件、Specification，就是领域模型这门“建模”语言的“单词”。给了我们一系列分析工具，帮我们分析出“领域”现象背后的“本质”。
所以，换句话说，本质是业务流程和系统流程不一致带来许多问题， 需要抽一个中间层，这个中间靠近业务/领域，所以以“领域”方式描述，但又不能易变，所以必须找到业务中不变的部分（即本质），来减少系统流程的变动。
如何用代码有效描述业务视角
领域驱动设计学习输出DDD 改变了传统软件开发工程师针对数据库进行的建模方法，从而将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为，通过合理运用面向对象的封装、继承、多态等设计要素，降低或隐藏整个系统的业务复杂性，并使得系统具有更好的扩展性，应对纷繁多变的现实业务问题。
- 传统项目中，架构师交给开发的一般是一本厚厚的概要设计文档，里面除了密密麻麻的文字就是分好了域的数据库表设计。言下之意：数据库设计是根本，一切开发围绕着这本数据字典展开
- 我经常会做一个假设：假设你的机器内存无限大，永远不宕机，在这个前提下，我们是不需要持久化数据的，也就是我们可以不需要数据库，那么你将会怎么设计你的软件？这就是我们说的 Persistence Ignorance：持久化无关设计。首先一点，领域模型无法通过数据库表来表示了，就要基于程序本身来设计了。
- 按照 object domain 的思路，领域模型存在于内存对象里，意味着得 通过 类图 而不是ER图来描述业务。用类 比用 数据库表 有更丰富的表达方式：通过引用来表达多对多关系、封装、继承和多态等。
领域驱动设计和开发实战从设计和实现的角度来看，典型的 DDD 框架应该支持以下特征：应该是一个以 POJO（这里说的应该是充血对象）为基础的架构；领域第一，基础设施第二：PersistentObject只是表达了一种存储方式而已， 跟业务毫无关系。
领域模型设计
领域模型：失血、贫血、充血
我们必须将应用程序的业务逻辑从服务层迁移到领域模型类中，为何呢？ 先来看看贫血模型和充血模型的对比。
假设我是一个服务类，你是一个域模型对象。如果我让你从屋顶上跳下来，你会喜欢我这样的决定吗？跳下来会摔伤，自己没有脑子或被洗脑，变成僵尸，只听从执行，不思考自己的安全，这就是贫血模型的问题。
举个具体的例子，假设一个用户有很多收货地址
class User{
List<Address> addresses;
setter
getter
}
那么在为用户添加收货地址时，不得不有很多判空操作
class UserService{
void addAddress(User user,Address address){
List<Address> addresses = user.getAddresses();
if(null == addresses){
addresses = new ArrayList<Address>();
user.setAddresses(addresses);
}
addresses.add(address);
}
}
想象一下
- 如果有多个位置操作User的Address（这个例子针对这一点不是很适当），
if(null == addresses){...}会大量出现，代码量不大， 但会很丑。如果是电商业务，每一次购物都要做优惠券、红包、满减检查、余额不足检查等，这些逻辑有可能重复在各个Service中。 - 更复杂的成员变量
List<List>或者List<Map<String,String>> - 更复杂的逻辑，比如设定默认地址，地址判重等。
UserService.addAddress吐血表示，我只想添加个地址而已。
换成充血模型
class User{
List<Address> addresses;
public User(){
addresses = new ArrayList<Address>();
}
void addAddress(Address address){
addresses.addAddress(address)
}
}
class UserService{
void addAddress(User user,Address address){
...
user.addAddress(address);
...
}
}
从中可以看到，addresses的 初始化和 添加都由User 负责，代码简洁很多。
个人体会：
- 除了列表等简单场景，一定要避免ViewObject、BusinessObject/DomainObject、PersistentObject一对一，最起码ViewObject 不应该和PersistentObject 有直接的关系 ，否则代码中必然有一堆的对象转换工具类。
- PersistentObject一般由框架自动生成，不适合做改动，只提供setter/getter方法，或者说除了set/get什么都做不了。这样不得不很多逻辑放在XXService中，造成XXService的臃肿。直接暴露set/get很多时候是有不安全的。
- BusinessObject仅提供跟业务强相关的方法，很多XXService的事情建议挪到BusinessObject做，XXService只负责调用BusinessObject 以及处理 事务一致、权限检测等非业务逻辑。
- 数据类不只存在于PersistentObject中，如果一个类，外部对这个类的使用就是处理它的成员而跟类本身没关系时 都可以认为是数据类。
- 类尽量只对外暴露能力，而不是暴露数据。观察使用这个类的常见场景（包括输入和输出两个方向），提炼为方法放在这个类中，尤其是可以多应用函数参数。此时，该类内部的成员的数据结构如何变化便不重要了。
读写分离
DDD读写对待不一样的，写需要严格遵守分层结构。读不一定，看情况。
领域模型是用于领域操作的，当然也可以用于查询（read），不过这个查询是有代价的。在这个前提下，一个 aggregate 可能内含了若干数据，这些数据除了类似于 getById 这种方式，不适用多样化查询（query），领域驱动设计也不是为多样化查询设计的。 查询是基于数据库的(比如 获取某数据的列表，这是一个查询需求，不算业务模型之内。业务模型一般侧重于 几个抽象 以及 抽象之间的相互作用)，所有的复杂变态查询其实都应该绕过 Domain 层，直接与数据库打交道。
横着看
DDD不只是指导写代码
领域驱动设计学习输出面对客户的业务需求，由领域专家与开发团队展开充分的交流，经过需求分析与知识提炼，获得清晰的问题域。通过对问题域进行分析和建模，识别限界上下文，利用它划分相对独立的领域，再通过上下文映射建立它们之间的关系，辅以分层架构与六边形架构划分系统的逻辑边界与物理边界，界定领域与技术之间的界限。之后，进入战术设计阶段，深入到限界上下文内对领域进行建模，并以领域模型指导程序设计与编码实现。若在实现过程中，发现领域模型存在重复、错位或缺失时，再进而对已有模型进行重构，甚至重新划分限界上下文。
小结
其实简单点讲，就是传统方式 本质为 以数据库表来描述 业务模型，而领域驱动 以 类图（类及相互作用关系）来描述业务模型。明显的，表达手段越多（类图丰富的表达手段，比如继承、多态等） ，便越容易 描述复杂事物，也更容易应对变化。
2018.6.20 补充 大家一直在谈的领域驱动设计（DDD），我们在互联网业务系统是这么实践的 本文字字珠玑，适合细读。