前言
在技术开发中，领域驱动设计（Domain Driven Design，简称DDD）理念倍受推崇。最近自己也再次读了一遍Eric Evans 的《领域驱动设计 —— 软件核心复杂性应对之道》。本篇来谈谈领域驱动设计理念如何对产品设计的一些启发。
什么是领域？
个人对领域的理解，可以认为领域是某个行业的业务知识。软件产品设计本身就是为了解决某个行业特定的业务问题，因此软件产品设计者本身需要能够充分理解相关的业务知识，也就是我们经常提到的，产品经理需要成为行业专家。
统一领域模型
软件产品设计者仅仅掌握领域知识是不够的，还需要对领域知识进行建模，形成领域模型。举个例子，我们的地球仪其实就是对地球的一个建模。领域模型的目的其实就是在团队里面传播和沉淀领域知识，确保设计、开发、测试人员所理解的领域知识是一致的，这样才能减少类似“这个地方你又没说清楚”的问题。在实际的产品开发过程中，我们很多问题其实是团队不同人员对领域知识的理解不同造成的。
然而，模型的表达会有很多种方式，比如文档、原型、思维导图、UML 图等等，那么该采取哪种形式来表达领域模型呢？ Eric Evans 提出了一个统一语言（Ubiquitous Language）的工具，这个工具有点类似 UML，但是并没有那么严格。其实，用什么工具是其次的，重要的这个工具表达出来的东西能够让业务人员、产品设计人员、开发人员和测试人员都能够明白其实的领域知识，同时需要有统一的规范。在表达具体业务对象定义、关系描述方面，个人建议可以参考 UML 的规范。
如何进行领域建模？
领域驱动设计的关键是采取合理的方式对领域进行建模，也就是将物理世界的业务映射到软件产品中，最终使得软件产品能够承载实际的业务。个人的建议是可以从如下几个方面来进行领域建模：
名词概念：在实际需求调研过程中，我们会听到很多专业领域中的名词。对于产品经理而言，这些名称很多是陌生的。对于产品设计而已，名词意味着一个个具体的业务对象，如果一个名词经常在业务人员口中出现，那么就需要特别注意。比如，我们看 CRM 系统中，会经常出现“客户公海”、“线索”、“商机”、“陌拜”这类名词，搞清楚这些名词代表的含义会让我们对领域知识有更深入的理解。因此，弄清楚名词概念是建模的第一步。
业务对象关系：业务对象的关系是软件设计中最为复杂的部分，一个中大型产品可能会存在错综复杂的关系，而产品设计除了梳理清楚业务关系外，一个很重要的工作是简化关系。举个例子，一个国家在历史上会存在多个总统，但是在一定时间段内只会有一个总统，通过添加时间段的约束，我们就把一个一对多的关系简化成了一对一的关系。
业务规则：业务规则用于对业务进行约束，以保障业务的合理开展。有些业务规则比较简单，例如表单的校验规则；有些业务规则则很复杂，例如电商平台中的秒杀业务规则。业务规则的处理相当考验产品经理的能力，很多开发人员会抱怨业务逻辑老是改来改去，其实很多时候改的就是业务规则。这里，一方面是产品经理在设计产品的时候，没有深入与业务方沟通业务规则，另一方面则是对业务规则的处理上比较随意 —— 比如让开发人员直接写死代码。有些业务逻辑会被其他逻辑替换，或经常发生改变，这个时候就可以参考策略（Policy）设计模式。把这部分业务逻辑提取到一个单独的“策略”对象中，实现规则与它所控制的行为区分开，从而可以使得规则易于替换。典型的应用场景就是优惠政策。一件商品可能同时满足多个优惠政策，因此可以把优惠政策单独抽离出来用于计算最终的商品优惠后价格。这样，即便更换了优惠政策，主体的计算过程只需要将优惠政策替换即可，而无需修改其他部分。
应用场景：应用场景在《领域驱动设计》中称之为上下文（Context）。上下文一方面是描述了某项功能的具体应用条件，另一方面可以为业务划定边界，从而帮助我们拆分或合并业务模块。通过上下文可以将高度相关的业务内聚为一个模块，而将不相关的分离到其他模块，从而保持单个模块的精炼。举个例子，我们在设计与第三方系统对接的模块时，就需要很清晰地将与第三方对接的部分从业务模块中剥离形成单独的模块，然后通过约定的规则与业务模块进行交互。这样做的原因是，第三方的对接是不受控的，如果发生变更，我们只需要更改剥离出去的模块，而无需修改业务模块。
责任归属：责任归属在梳理业务流程中非常重要。产品经理经常会梳理业务流程，但是业务流程的核心要义其实更多是划分责任归属，而流程的推进就是责任的转移。书中提到了货运的例子，在货物经过不同的流程环节时，实际上就是货物在托运人、承运人和收货人直接的责任转移。对于 B 端产品而言，一个业务流程通常会经过多个角色，这个时候明确每个角色承担的责任就非常重要。一方面是有助于权限系统的设计，另一方面则是能让参与系统设计的人清楚地了解有哪些角色，以及每个角色承担的职责。
这里需要提醒一下，对于刚做产品设计的人来说，会关注业务流程和功能的实现，而会忽略最核心的领域知识。结果导致产品难以贴合业务，扩展性不好。领域知识包括了业务对象概念、对象间关系、业务规则、应用场景等等。设计产品前，先把这些理清楚，再做产品流程梳理和功能设计会让整个设计更加合理和易于扩展。
怎么推进领域驱动设计？
说实话，要推动领域驱动设计还是挺难的，关键还在于产品和技术 Leader 的决心。我们大多数时候都是忙于需求分析、原型设计、开发交付，而很少停下来思考我们的设计和真实的业务契合度。这恰恰导致了一个恶性循环 —— 我们陷入了不断调整产品功能却无法满足业务需要的怪圈。
书中针对推进领域驱动设计，给出了6个要点：
决策必须传达到整个团队：如果不能确保团队中的所有人都知道策略并去遵守它，那么策略也就失去了运用。无论开发什么系统，都不要管理层所授予的权力来强制地推行战略决策，而应该更多地关注开发人员与策略之间的实际关系。
决策过程必须收集反馈意见：团队需要真正理解项目需求和领域概念的开发人员。单独依靠架构师不一定能够设计出好的应用架构——毕竟应用架构是为业务服务的。
计划必须允许演变：软件开发是一个动态的过程，如果决策过早固定下来，开发团队可能束手束脚，失去解决问题的灵活性。有了积极的反馈之后，当遇到障碍或是出现了意想不到的机会时，创新也就自然而然涌现出来了。
架构团队不必把所有最好、最聪明的人员都吸收进来：如果都把最优秀的人员纳入了架构团队，那么意味着业务开发团队的水平都是偏低的，这会导致业务领域模型设计开发水平糟糕。即便有好的架构，业务层还是很难出众。让业务开发人员也能够参与架构设计中，会让架构更贴合业务。
战略设计需要遵循简约和谦逊的原则：我们必须严格约束自己，从而使设计出来的组织原则和核心模型精简到只包含能够显著提高设计清晰度的内容。
对象的职责要专一，而开发人员应该是多面手：让开发人员在编写业务代码的时候，也能参与需求分析、架构设计，这会有助于提高整个团队的设计开发水平。
这里特别说一下第4点和第6点。实际开发团队分工上，通常会让高水平的程序员负责技术基础设施 ——比如架构设计，底层组件的构建，而把水平一般的开发人员分配去做业务开发。很多程序员也更愿意去往架构方向上发展，因为掌握了“通用”的技能，简历上更丰富。 然而，缺乏高水平的程序员去理解领域知识的话，对业务领域的建模很可能没法反应核心的领域知识，结果即便有良好的底层技术支撑，业务层面可能也一团糟——最终所谓好的架构也没有地方发挥价值。 因此，建议对核心领域的设计开发，一定要高水平的产品、开发人员参与。并在团队内部沉淀核心领域知识，帮助整个团队理解核心业务，提高团队人员对业务的理解。
总结
个人对领域驱动设计最深的感触还是在领域知识的理解过程上。我们的 SaaS 产品一开始立项开发的时候，获取到的领域知识其实非常片面，结果是产品推向市场后被客户各种吐槽。然而，随着种子客户的深入使用，我们与客户的交流也变得更多，对业务领域知识的理解逐步清晰。这个过程中，我们会发现之前很多的概念、关系的理解和实际业务存在不小的偏差，于是不得不逐步调整。到客户增长到一定量之后，发现很难继续按照原有的设计继续推进，于是重构就提上了日程。重构，对于技术开发来说可能更关注性能瓶颈的解决，而对于产品设计来说则是领域模型的升级迭代。
从这个过程中得到的经验就是，虽然我们很难做到一开始就对领域知识理解非常深刻，但是应该趁早梳理业务领域知识，建立领域模型。这需要我们产品经理与业务人员进行高频次、深入的沟通交流，并且能够将领域知识准确地传达给测试、开发人员，以保障最终开发出来的产品能够高效解决行业的业务问题。
