你可以，不代表你应该。
（Just because you can, doesn’t mean you should.）
——施莉琳•凯尼恩
7.4 DDD的优势
通过上面的介绍，相信读者对DDD有了一些认识，接下来对DDD的优势会更容易接受。如果一开始不能接受DDD也没有关系，我其实也经历过“排斥—接受—使用”的过程。当真正领会DDD的精髓之后，我就再不愿意回到以前的开发模式了。下面将DDD带来的核心好处总结如下。
7.4.1 统一语言
统一语言（Ubiquitous Language）的主要思想是让应用能和业务相匹配，这是通过在业务与代码中的技术之间采用共同的语言达成的。业务语言起源于公司的业务侧，业务侧拥有需要实现的概念。业务语言中的术语由公司的的业务侧和技术侧通过协商来定义（意味着业务侧也不能总是选到最好的命名），目标是创造可以被业务、技术和代码自身无歧义使用的共同术语，即统一语言。代码、类、方法、属性和模块的命名必须和统一语言相匹配，必要的时候需要对代码进行重构！
试想，在PRD文档、设计文档、代码以及团队日常交流中，如果有一套领域术语是统一无歧义的，是否会极大地提升沟通和工作效率？在日常工作中，因为概念理解不一致，或者语言表达上的问题，导致沟通效率低，甚至发生误解的情况实在太多了。所以，明确概念、形成统一语言至关重要。
7.4.2 面向对象
DDD的核心是领域模型，这一方法论可以通俗地理解为先找到业务中的领域模型，以领域模型为中心，驱动项目开发。领域模型的设计精髓在于面向对象分析、对事物的抽象能力，一个领域驱动架构师必然是一个面向对象分析的大师。
DDD鼓励我们接触到需求后第一步就是考虑领域模型，而不是将其切割成数据和行为，然后用数据库实现数据，用服务实现行为，最后造成需求的首尾分离。DDD会让你首先考虑业务语言，而不是数据。DDD强调业务抽象和面向对象编程，而不是过程式业务逻辑实现。重点不同，导致编程世界观不同。
7.4.3 业务语义显性化
统一语言也好，面向对象也好，最终的目都是为代码的可读性和可维护性服务。统一语言使得我们的核心领域概念可以无损地在代码中呈现，从而提升代码的可理解性。例如，在银行转账的案例中，按照事务脚本的写法来写“透支策略”的业务概念，其含义完全被淹没在代码逻辑中没有突显出来。但是，如果我们使用策略模式将其抽象出来，让业务语义得到显性化的表达，代码的可读性就会提升很多。
面向对象也是让代码尽量体现领域实体和实体之间的关系原貌，所以目的也是业务语义被显性化地表达，显性化的结果是代码更容易被理解和维护，殊途同归，一切都是为了控制复杂度。在软件的世界里，任何的方法论如果最终不能落在“减少代码复杂度”这个焦点上，那么都是有待商榷的。
7.4.4 分离业务逻辑和技术细节
代码复杂度是由业务复杂度和技术复杂度共同组成的。实践DDD还有一个好处，是让我们有机会分离核心业务逻辑和技术细节，让两个维度的复杂度有机会被解开和分治。如图7-8所示，核心业务逻辑是整个应用的核心，最好只是简单Java类（Plan Old Java Object，POJO）。也就是说，核心业务逻辑对技术细节没有任何依赖，依赖都是由外向内的，即使有由内向外的依赖，也应该通过依赖倒置来反转依赖的方向。通过这样的划分，Entities只要安安心心地处理业务逻辑就好，业务逻辑越复杂，这样划分带来的好处越明显。
为什么说数据库、框架和UI都是技术细节呢？
- 数据库：业务逻辑不应该受限于存储方式，也就是不论你是使用关系型数据库还是NoSQL，都不应该影响业务逻辑的实现。数据本身很重要，但数据库技术仅仅是一个实现细节。
- UI：UI只是一种I/O设备的呈现，Web、WAP和Wireless都是不同的I/O，我们的核心业务逻辑应该与如何呈现解耦，以及针对不同的端可以使用不同的适配器（Adaptor）去做适配。
- 框架：不要让框架侵入我们的核心业务代码，以Spring为例，最好不要在业务对象中到处写@autowired注解。业务对象不应该依赖框架。
这么说来，这些技术细节是不重要了吗？不是的，技术细节是一个系统的必要组成部分，也非常重要。技术细节和核心业务逻辑是两个维度的重要性，如果把软件比喻成一个人，那么核心业务逻辑是大脑，技术细节是身体，二者都很重要，分开处理主要是为了降低复杂度。
7.5 DDD的核心概念
7.5.1 领域实体
毫不夸张地说，我们的软件系统就是对现实世界的真实模拟。如图7-9所示，现实世界中的事物在软件世界中可以被模拟成一个对象：该事物在现实世界中被赋予什么职责，在软件世界中就被赋予什么职责；在现实世界中拥有什么特性，在软件世界中就拥有什么属性；在现实世界中拥有什么行为，在软件世界中就拥有什么函数；在现实世界中与哪些事物存在怎样的关系，在软件世界中就应当与它们发生怎样的关联。这正是面向对象编程的核心思想，也是DDD中寻找领域实体的核心思想。
假如现在你需要设计一个中介系统，一个典型的User Story是“小明去找工作，中介让他留个电话，有工作机会就会通知他”。我们要如何寻找该业务中的关键领域实体呢？一个简单的方式就是“找名词”，分析这些名词，不难得到以下可能成为实体的候选项。
- 小明：一个求职者。
- 电话：求职者的相关信息，可以是一个属性。
- 中介：可以拆解为中介公司和中介公司的员工两个概念。
- 工作机会：对于中介系统来说，工作机会应该是最关键的实体之一。
- 通知：作为名词是一个实体，但是作为一个动词是在暗示我们可以使用Notify。
是的，对于这个简单的User Story，这样分析就可以了。当然，随着更多的Story被加入，我们会补充更多的实体，比如增加了“中介费是按照小明第一个月工资的30%收取”，那么就可能要引入“订单”和“支付”等实体。
以上就是我在实际工作中寻找领域实体的大致过程。从方法论的角度来说，也叫作“用例分析法”，详细的步骤会在7.6.1节中介绍。
