前言
正如领域驱动设计之父 Eric Evans 所著一书的书名所述，领域驱动设计（Domain Driven Design）是一种软件核心复杂性应对之道。
在我们解决现实业务问题时，会面对非常复杂的业务逻辑。即使是同一个事物，在多个子业务单元下代表的意思也是不完全一样的。比如「商品」这个词，在商品详情页语境中，是指「商品基本信息」；在下单页语境中，是指「购买项」；而在物流页面语境中，又变成了「被运送的货物」。
DDD 的核心思想就是让正确的领域模型发挥作用。所谓「术业有专攻」，DDD 指导软件开发人员将不同的子业务单元划分为不同的子领域，在各个子领域内部分别对事物进行建模，来应对业务的复杂性。
Part 1
重构优惠中心的背景
我们在实际的开发过程中都遇到过这种情况，最初因为业务逻辑比较单一，为了快速实现功能， 以及对成本、风险等因素的综合考虑，我们会为业务统一创建一个大的模型，各个模块都使用这同一个模型。但随着业务的发展，各子领域的逻辑越来越复杂，对这个大模型的修改就会变成一种灾难，有时明明是要改一个 A 子领域的逻辑，却莫名其妙影响到了 B 或者 C 子领域的线上功能。
优惠中心就是一个例子。优惠中心主要负责马蜂窝各业务线商品的优惠活动管理，以及计算不同用户的优惠结果。「商品管理」和「优惠管理」作为两个不同的业务单元，在初期被设计为共用一个商品模型，由商品模块统一管理。
图1 ：初期商品模型
出现的问题
随着业务的发展，优惠的形式不断推陈出新，业务形态逐渐多样，业务方的需求也越来越个性化，导致后期的优惠中心无论从功能上还是系统上都出现了一些具体的问题：
1. 功能上来说，不够灵活
优惠信息是作为商品信息的一个属性在商品管理模块配置的。比如为了引导用户使用 App 需要设置 A 类型优惠，就通过在商品信息的编辑页面增加一个 A 类型优惠配置项实现；如果某个商品的 A 类型优惠需要在 0:00 分生效，业务同学就必须在电脑前等到 0:00 更新商品信息来上线优惠活动。
另外，如果想要创建针对所有商品都适用的优惠，按照之前的模式，所有的商品都要设置一遍，这几乎是不可接受的。
2. 从系统层面看，不易扩展
优惠信息存储在商品信息中，优惠信息是通过商品管理模块的接口输出的。如果要新增一种优惠类型，商品信息相关的表就要增加字段，商品的表会越来越大；如果要迭代一个优惠的逻辑，就有可能影响到商品管理模块的功能。
3. 不利于迭代
由于优惠信息仅仅作为商品的一个属性，没有自己的生命周期，所以很难去统计某一次设置的优惠的投入产出比，从而指导后续的功能优化。
重构优惠中心的预期
系统层面上 ，要把优惠相关的业务逻辑独立出来，单独设计和实现；应用层面上 ，优惠中心会有自己的独立后台，负责管理优惠活动；也会有独立的优惠计算接口，负责 C 端用户使用优惠时的计算。Part 2
为什么选择 DDD
避免贫血模型
基于传统的 MVC 架构开发功能的时候，Model 层本质上是一个 DAO 层，业务逻辑通常会封装在 Service 层，然后 Controller 通过调用 Service 层来完成对外的功能。这种模式下，数据和行为分别被割裂到了 Model 和 Service 两层。我们把这种只承载数据，但没有业务行为的 Model 称为「贫血模型」。
我们在和业务方了解需求的过程中，使用到的对象都是现实业务的映射，是行为和属性的综合体。需求确定好之后，我们开发的过程中，人为把行为和数据拆分成了两部分，做了一次转换。随着需求的迭代，人员的更迭，开发看到的代码和业务方的需求越来越对应不上，导致很多代码谁也不知道对应的是什么业务逻辑，这种现象被称为由贫血模型带来的「失忆症」，最终导致的是一个维护成本极高的大泥潭系统。
领域驱动设计的核心就是基于业务逻辑去建模，避免贫血模型，减少设计和开发过程中对业务信息的丢失和转换。在业务逻辑迭代的过程中，系统通过调整对应的业务模型就可以完成迭代。
Part 3
落地过程
关键点：业务逻辑抽象
要做到基于业务逻辑建模，就要合理地抽象。因为业务表象千差万别，产品经理和软件设计人员需要和业务专家深入交流，并且从离散的信息中抽象出业务内在的逻辑。
比如旅游业务售卖的商品和标品不同，有些优惠是不考虑人群的，比如使用优惠券，所有类型的库存都可以享受；但如 N 人 N 折这类优惠，成人价可以享受，儿童价和单房差就不可以。基于这个特点，我们对优惠中心的商品模型做了抽象，抽象出来「是否可以参与件数计算」和 「是否可以参与价格计算」两个通用属性。这样既实现了基于业务逻辑建模，又不会陷入业务逻辑千差万别的表象中。
3.1 战术设计
第一步：统一语言，提炼关键词
准确的语言对于产品、运营、开发等各方对齐需求非常重要，我们需要将优惠逻辑当中的概念抽象为各方都能理解的词语，以达成共识。作为开发人员来说，对领域的理解一般来说是比较少的，为了抽象出合理的语言让产品和业务方都能理解，就需要充分理解业务背景和需求。在熟悉业务和需求的过程中，提炼出若干关键字，这些关键词就是最初产生的领域概念和通用语言。 比如：
优惠类型 ：表示一种优惠规则和对应的优惠方案。比如早鸟优惠，就是早多少钱买（优惠规则），减多少钱/打几折（优惠方案）;优惠活动 ：拥有完整的生命周期，需要包含时间、平台、人员、商品等（限制维度）的某种优惠类型的使用过程信息；优惠发现 ：根据指定的商品、人员和平台，找出可以使用的优惠活动列表服务；优惠计算 ：根据指定的商品、人员、平台以及购买数量，计算出这一次购买行为可以享受的优惠金额及优惠明细；优惠排序 ：各种优惠类型在计算的时候是有先后顺序的，如果有打折的优惠存在，那顺序不同，计算的结果也会不同；优惠互斥 ：某些优惠之间存在互斥的关系，比如使用了金卡 96 折优惠，就不能使用马蜂窝优惠券。第二步：抽象领域模型
根据单一职责的原则，一个领域概念对应一个领域对象。领域对象有实体 和值对象 之分：
实体 ：实体是有状态的和唯一标识的，包含属性和行为；值对象 ：值对象是无状态的，是只读的，包含属性和行为。区分实体和值对象对系统设计有很大意义，实体是我们需要重点关注和设计的，而值对象则只使用它的「值」就可以了。这样可以简化系统的复杂度，将精力聚焦在核心领域对象。不难理解，优惠活动毋庸置疑是一个实体，优惠类型就是一个值对象。
但也存在某些业务行为是不能归于某个实体或值对象的，可以将它们归为领域服务：
领域服务 ：领域服务本质上就是一些操作，不包含状态，通常用于协调多个实体。实体和值都属于领域对象，领域对象之间的交互逻辑不能放在领域对象内部，必须由服务来实现，从而有效地保护领域模型。有一些领域逻辑，比如「优惠排序」和「优惠互斥」，他们涉及到多个优惠类型，也就是多个领域对象。如果也被设计为领域对象，就打破了单一职责的原则，所以我们把这部分跨多个领域对象的业务逻辑放到「领域服务」层。
第三步：抽象领域对象之间的关联关系
将相关联的领域对象进行显式分组，来表达整体的概念（也可以是单一的领域对象），也就是「聚合」 。
比如优惠活动是优惠类型、优惠范围等的聚合；优惠类型是优惠规则和优惠方案的聚合；优惠规则是限制维度的聚合；优惠方案是优惠手段的聚合：
图2 ：关联关系示意
聚合的主要功能是把领域对象分组，外部的唯一访问点就是聚合根 ，这样可以避免处理领域对象间的一一对应关系，只需要处理聚合和聚合之间的关系就行了。
第四步：走查场景，调整领域模型
领域模型的调整是贯穿整个设计和开发过程的，随着业务的调整，领域模型也需要调整 。比如优惠中心后期引入了会员卡的优惠类型，那么就需要把优惠券这个优惠类型的显示，调整为与会员卡互斥的优惠券和与会员卡不互斥的两种。
第五步：简化设计，降低系统复杂度
建模的本质是对现实事物的一种简化和抽象，指导我们忽略和问题域无关的事实，提取和问题域息息相关的信息。以优惠中心为例，最初的方案里我们设计了优惠类型管理的功能，根据不同的优惠规则和优惠方案自动组合成不同类型的优惠类型。但是可以预见，未来的优惠类型是有限的，并且每个优惠类型都有会自己的特殊配置，比如 N 人优惠里的 每 N 人/第 N 人；早鸟中的提前 N 天等。也就是说，根据优惠规则和优惠方案自动生成优惠类型基本是没有使用场景的，因此也就去掉了这个设计。
再如，对优惠的限制我们最初是设计在优惠活动维度，经过权衡，为了降低系统复杂度，最后实现在了优惠类型层面。以「蜂抢」优惠类型为例，它的规则是所有的蜂抢活动都是 1 个用户只能抢一次，没有必要把这个限制放在优惠活动维度，在优惠类型层面控制就可以了。
3.2 战略设计
战略设计处理的是不同限界上下文之间的拆分和集成逻辑 。限界上下文比较抽象，结合我们在文章开始提到的不同语境中的「商品」例子来理解，同一个词如果不说明白所处的语境，是无法准确描述清楚其表达的含义的。「语境」其实就是「上下文」，对应不同「子领语」。同理，如果不在一个限定好的上下文中去设计领域模型，设计出的领域模型是不清晰的，它就会同时支持多个上下文。
这里需要说明一点，如果是从零搭建一个全新的电商系统，首先需要做的应该是战略设计。而优惠中心是建立在现有大的电商系统基础上，相当于作为其中一个子领域进行重构，所以我们才会先来做战术设计，再考虑在完整的电商系统下它与外部其他环境之间的关系，也就是战略设计。
优惠中心内部场景区分
优惠中心包括了服务于 B 端用户的优惠活动管理和服务于 C 端用户的优惠计算这两个不同的子业务单元：
图3 ：优惠中心内部场景区分
优惠活动 处理的是优惠活动的增删改查，以及配套的统计等业务；优惠活动在这里是一个实体，有完整的生命周期，有上线、下线等状态，可以被创建和删除；优惠计算 处理的是一个订单能享受哪些优惠，并减多少钱的问题；在这个场景里，优惠活动是一个值对象，只提供优惠计算需要的必要参数即可。优惠中心与外部系统集成
在整个电商系统的环境下，优惠中心作为一个子域，处于自己的限界上下文当中。使用优惠中心服务的详情页、下单页都处于自己各自的限界上下文， 所以调用优惠中心的时候就需要设计它们之间的上下文映射方式。
调用和被调用方使用的战略设计方法通常有以下几种：
客户方-供应方 ：适用于同一个团队之间的协作，上游会有严格的自动化测试，来保证给到下游的数据是一定符合约定的；遵奉者 ：适用于不同团队协作，且上游不关心下游的标准，下游又完全「逆来顺受」地接受了上游给的数据的场景；防腐层 ：适用于上游不关心下游的标准，但是下游不甘心「逆来顺受」，就增加一层，来做转换处理，保持下游系统的独立性；开放主机服务 ：适用于中台（通用能力平台），对接方非常多，业务重复度高，并且已经有完善的测试机制和通用的模型。结合我们的实际情况来看，调用优惠中心的可能会是不同团队的开发人员，而优惠中心又不想被不同的上游侵入内部设计中，所以「客户方-供应方」和「遵奉者」模型都不适合；另外优惠中心前期接入方会比较少，而且会不断迭代，使用「开放主机服务」也不太合适。综合考虑下，防腐层 的设计比较适合优惠中心。
下图是优惠中心的业务架构示意，中间的应用服务层采用的就是防腐层的设计，反映优惠中心与外部系统集成时的上下文映射关系：
图4 ：优惠中心业务架构
3.3 架构实现
优惠中心选择的是经典的分层架构 。从上到下为用户接口层、应用服务层、领域层和仓储层。图中不同的颜色块分别对映外部服务、应用服务、领域服务、聚合根、实体、值对象和仓储。
图5 ：优惠中心分层领域模型
用户接口层 ：处理和终端用户的交互逻辑；应用服务层 ：负责封装和转换领域层的返回数据给用户接口层；领域层 ：优惠中心的核心逻辑都在这一层，包括领域对象和领域服务。仓储层 ：仓储层负责把内存中的领域对象落地到存储介质，也负责从存储介质拿到原始数据后构造领域对象给领域层使用；这一层对领域层隐藏了底层的存储细节。虽然仓储层处在领域层下方，但是我们实现过程中采用了依赖注入的方式，将仓储层的具体实现注入到领域层中。Part 4
问题及近期规划
1. 价格层优惠
现在公司面没有一个统一的商品中心，并且各业务线对商品的定义差别很大。比如自由行的商品包括出行日期、价格类别（成人价、儿童价）和套餐类别等层级；而火车票的商品包含座次、席别、目的地和出发地等层级。
如果优惠中心抽象出一种通用的商品层级来适配各个业务线，那实际上就是优惠中心要对商品进行标准定义，但是这个标准与后续商品中心的标准定义很有可能是不一致的，如果不一致优惠中心就要做大的改版。所以最终的解决方案可能还要通过推进统一商品中心的建立来解决。
2. 性能问题
领域驱动设计带来的弊端就是类的增多。目前优惠中心的技术栈基于 PHP， PHP 是一种解释型语言，在DDD 模式下即使有了 OPCode 等缓存技术，执行阶段的耗时相对其他静态数据类型的语言还是较大。所以后面计划将优惠中心使用 Java 技术栈重构，来进行性能上的优化。
Part 5
小结
本文介绍了马蜂窝电商优惠中心基于 DDD 进行重构的一些实践经验。DDD 的思想也帮助我们在业务迭代的过程中将架构设计得更加合理。
当然，是否采用业务驱动设计的思想，需要取决于业务和团队的实际情况。在马蜂窝业务的快速发展下，我们在架构设计上还将做更多的探索，也将持续与大家交流。
近期评论