DDD系列文章第4篇：DDD如何做战略设计，做个懂业务的技术 -- 知识铺

稍微了解DDD的都听过它的战略设计和战术设计两个主要步骤。显而易见的是战略设计是前序动作战术设计是后继动作，两者的关系类似软件开发过程中的概要设计和详细设计。但大部分人心中一定也有很多疑惑，包括本人，DDD战略设计和平时大家说的公司战略是什么关系？DDD战略设计的输入从哪里来？大部分人觉得战略是公司高层负责的事情，难道DDD战略设计需要公司高层参与进来吗？既然都是对问题域的剖析，它跟产品经理的那些业务分析方法有什么关联？它跟架构师的那些企业架构方法又有什么关联？我觉得有必要先探讨一下。

1.1 大多数人眼中的战略是什么？

作为职场人相信大家对战略一词并不陌生，但战略到底是什么？大家的答案不会相同。总结一下有这么两个角度。

战略关联了很多概念

和战略一起经常被提及的概念还有使命、愿景、价值观、目标等等。当我们讲战略的时候最好区分一下。

使命是什么？使命是解释一家公司存在的理由，诠释了一家公司存在的意义，是这家公司的梦想。它往往很抽象，很『不接地气』。比如迪斯尼公司的使命是『制造欢乐，销售欢乐』。
愿景是什么？使命是讲公司存在价值的，愿景是讲公司将来能做到什么程度，成为什么样子。比如苹果电脑公司的愿景是『让每人拥有一台计算机』。愿景很有画面感，对内可以团结并激励大家。
价值观是什么？价值观也是公司文化，它指公司行为做事过程中的原则，一些必要且清晰的原则就衍生出了公司的规章制度。
目标是什么？目标和规划往往等同，要说清楚怎么去做，分几个阶段，先做什么后做什么。目标的实现也就引出了战术部分。

细看一下这几个概念既有紧密联系，也有各有侧重。那战略到底跟这几个概念什么关系呢？

战略也分层次，需要拆解

广义上的战略包含了使命、愿景、价值观和目标。平时说的战略主要指目标和规划。也就是在战略之上是使命、愿景和价值观，战略的条件和约束来自于使命和愿景。这也是很多公司大佬经常说谈战略之前要先想清楚公司的使命、愿景和价值观。从使命到规划一步步在逐渐变得清晰和具体，而战略就是要把使命和愿景里面不接地气的概念变得具象化，变成团队可以理解，可以操作的一件件事。

另一方面，要把一个概念变成可操作的一件件事并不简单，特别是涉及到一个组织，如何让组织的成员都能准确理解。因此针对具体的目标会有很多不同的手段来帮助这个拆解过程变得更顺利。因为战略靠组织来达成，而组织是分层次的，因此战略也分层次。所以不要轻易理解为战略是公司高层的事，公司的战略需要一个产品来承接，不同的职能部门分担不同的战略工作。

拿产品研发领域来说明，战略目标是要开发一款新产品或者升级一个旧产品。如何拆解这个战略，它往往要经过几个层次从抽象到具象，抽丝剥茧。之前的文章产品经理需要具备哪些能力？也有讲到过产品需求的拆解。

战略之上是产品的使命和愿景。落地层面可以是产品愿景、产品价值主张。辅助的分析手段有用户旅程分析、商业模式画布分析、需求价值分析。这个阶段聚焦分析用户的痛点、产品提供的价值。
接下来是定义产品的业务范围，产品主路径。内部需要哪些组织协作，提供哪些流程满足外部用户的需求。辅助的分析手段有业务流程图。如果在业务流程基础上加上角色和上下文含义，业务流程分析也可演变为业务场景分析。
针对业务流程图还需要进一步细化流程的边界，哪些是用户交互范畴，哪些是组织内交互范畴，哪些是看不见的支撑范畴。辅助的分析手段有服务蓝图。
业务流程图和服务蓝图都是在完善业务流程描述，接下来要把流程图拆解出功能，定义出具体的功能细节，也就是功能需求说明。辅助的手段有业务功能图，用户用例图。值得提一句的是，拆分业务功能的时候，应当加上外部使用者的视角，把一个业务功能视为一次有意义的业务服务，也就是技术实现阶段对应的系统模块的接口/API设计，这也是API First思想的着陆点之一。

以上步骤哪些是战略部分呢？取决于你站在哪个角度。如果站在具体需求的技术实现角度，那么前四步都可视作战略。这几个步骤虽然把问题一步步拆解的更为简单易懂了，但如果产品很复杂，包含了很多功能模块，实际拆解过程中困难会很大。为了把复杂系统的拆解变得更易于执行，让组织成员更有效率地理解产品的业务逻辑，让拆解的结果能够和系统开发做好衔接绑定工作，DDD提出应该在这几个步骤基础上做点增强，到底增强了哪些方面呢？这就是DDD的战略设计内容。

1.2 DDD的战略设计要做什么？

如果产品功能太复杂，一个业务流程往往就涉及很多产品和研发人员，整个团队对业务的理解从陌生到熟悉的过程将会很长，效率也低下。必须要找一个粒度，多大粒度才合适呢？DDD的战略设计提出『子领域』概念。有两层意思，一是子领域要有主次之分，即核心子领域、通用子领域、支撑子领域（注：有的场合下也把子领域简称为领域），便于规划资源到重要的子领域。二是子领域的范围要合适。子领域可能范围还是太大，仍然需要进一步细化。DDD的战略设计提出『限界上下文』（英文名是Bounded Context，下文简称BC）概念，在上下文里面定义业务的概念，既消除了二义性，也不会形成大杂烩的业务概念。

常规的产品分析步骤再结合『子领域』和『限界上下文』这两个粒度，就能比较准确的描述业务概念和概念背后的规则、逻辑。这也是DDD战略设计的目的，团队里只有达成了准确的业务概念理解后才能在日常沟通、文档编写、代码编写上形成一致。同时『限界上下文』也是技术架构里系统划分的输入，真正做到设计和实现一脉相承。

—

细说产品和业务的战略设计

战略设计即战略拆解，就是把一个问题变得更容易理解，更容易在团队内达成共识，更易于过渡到解决方案。拆解阶段很注重团队层面的对齐效率，因此可视化效果好的方法往往更利于对齐，因此也就更流行。下面介绍几种业界比较通用的拆解手段（分析和设计在这里统称为拆解），也包括DDD的战略设计。不同产品或者是产品的不同阶段应按需选取不同的方法灵活运用。同时也可以对比一下DDD的战略设计手段和常规的分析设计手段的联系和区别。注：本人专职研发方向，缺乏产品设计相关的一些方法论的实战，难免有纰漏。

2.1 商业模式画布

商业模式画布很流行，它包含9个问题，都是战略阶段要定义并回答的那些顶层问题。

这9个问题的核心是围绕外部的『客户』的利益展开的一些列公司运营活动，其中大致也能对应到公司不同的职能部门，比如一个开发商业软件的公司，可能有这些职能部门和分工：

市场渠道团队要回答『怎样让用户找到？』、『谁能帮我？』
客户成功团队或者运营团队要回答『怎样和用户打交道？』
产品和研发团队要回答『解决谁的问题？』、『解决什么问题』、『我要做什么？』、『我有什么？』
财务预算部门要回答『我要付出什么？』、『我能得到什么？』

2.2 产品愿景

产品愿景和商业模式画布有重合的部分，产品愿景更多的是对产品相关的几个问题进行细化。

针对『解决谁的问题』，更加细化出目标用户画像是什么？
针对『解决什么问题』，更加细化出用户的痛点是什么？产品的核心价值是什么？
针对『我要做什么』，更加细化出产品是什么？和竞争对手的区别？

产品愿景可以用非常简短的话概况这几个问题（正因为此，有时候也跟电梯演讲联系到一块），便于在团队内部达成共识和贯彻。甚至有时候对某些具体功能需求值不值得做犯难时，也能做为一种指引和评判依据。产品愿景的模板大致如下：

对于：（目标客户）；
目前存在：（问题&需求描述）；
我们提供：（产品名称）；
这是一个：（产品品类名）；
它能够：（满足需求&解决问题的方式描述）；
不同于以往的：（产品品类名）；
比如：（竞品名称）；
我们的产品：（核心卖点&差异化特性）；
而且符合：（公司愿景）。

2.3 业务流程图

前面的商业模式画布、产品愿景等分析都是聚焦外部用户的问题，接下来需要往组织内部如何执行靠近。第一步就是要回答为了提供这些产品价值需要哪些业务流程。一个业务流程就是用户对系统一次操作的前因后果，概况起来包括了4个要素：

谁（产品的使用用户）
在什么前提下（操作的前置条件）
做了什么（对产品施加了什么操作）
导致了什么（操作的结果，操作要达到的目的）

业务流程图一般用泳道图来绘制，通常纵向表示角色（也可按需加入横轴表示业务模块等），将业务流程从头至尾梳理清楚。下面是一个注册登录的业务流程示例图：

业务流程分析的3个注意事项：

用户调研的结果离真正的业务流程还有差距。在产品的用户调研阶段往往能收集到现实中用户操作的流程，但极有可能缺少某些要素，需要产品经理提炼和完善。
业务流程的范围取舍。业务流程也有主次之分，不可能面面俱到，如何取舍？可以借鉴精益创业模式里提出的MVP(Most Viable Product)的方法论，即可行且最小的业务范围。因为实际情况往往是成本有限，时间紧迫。还可以结合用户旅程分析，从用户的角度评估出用户对产品的体验心情高点和低谷，结合峰终定律尽量最大化体验峰值，消除体验低谷点，有取舍地建设旅程的关键流程。总之业务范围的裁减也是一门学问。
业务流程分析的补充。流程中用户的每次操作都有前因后果，进而可能引发后续操作。这也可能引发流程中某些操作步骤是不自洽的，缺乏逻辑基础，这时候往往是没识别到一些用户交互之外的系统后台行为。因此业务流程图可以结合服务蓝图，进一步识别出支撑着信息流动背后的后台系统行为。

2.4 服务蓝图

用户旅程图侧重于展示用户『端到端』的前台体验，业务流程图也是聚焦在用户的主要业务流程。服务蓝图则提供了一种补充。侧重于综合分析，不仅仅包括跟用户体验有关的前台业务，也包括后台的业务核心，服务如何交付，运营如何支撑等前台、后台和幕后流程。服务蓝图的示例图如下。

服务蓝图是从用户体验出发，进一步拆解出组织内部如何从后台支持用户的旅程，大部分靠程序系统，也有一些是系统外的运营流程。服务蓝图算是产品人员和技术人员结合的一个重要环节。实际操作过程有3个注意事项：

关注边界。前台和后台的边界在于是否通过产品界面进行交互，也就是上图中的可视线。进一步把交互细化为服务触点，也就是界面上的点击等动作。有些产品也少不了提供内部用户使用的界面，这就是内部交互线。
发现流程中遗漏的触点。每次交互必有前因后果，一定要顺着因果关系推导出缺失的触点。另外就是合并重复的触点，减少后期重复建设工作。比如电商系统里的商品在被用户浏览到之前一定要完成审核和上架动作。这个步骤往往能识别出很多用户看不到的后台行为，比如支付需要后台打通第三方支付系统，发短信需要后台打通运营商系统等。
相关人员要一起参加讨论。服务蓝图涉及到的组织内相关团队应该一起参与服务蓝图的内容讨论，特别是技术人员，传统的流程下产品需求的分析和设计只有产品参与，交到技术人员的时候是结论性材料，这样缺少了很多上下文，也错失了技术人员能贡献完善分析结果的机会。在业务流程图和服务蓝图过程中，可以结合事件风暴来做，但要注意区分触点和事件（两者不能等同），要把握好细节粒度，否则容易发散收不回来，讨论效率很低。

2.5 识别并划分子领域

在经过业务流程分析和服务蓝图分析后，团队对业务流程逐渐清晰起来。但业务流程毕竟只是主干，还有很多细枝末节要细化。如前面所述，在业务流程和具体的业务功能点之间还需要加入一个业务粒度，能够让这个过渡更顺利。这也是DDD对常规业务分析的一种补充，这个粒度就是『子领域』。以用户网上购物来说，从用户视角来看只要在界面上浏览商品、加入购物车、下单，支付几个点击动作就可以等着收货了。但从系统视角来看其中涉及到职能部门和很多后台系统。需要建设哪些系统能力不能只靠业务流程定义。如果加入DDD战略设计，那就要把业务领域划分为商品、购物车、订单、支付、物流等不同子领域，在子领域里继续拆解模块。

划分子领域的两层含义

第一层含义就是上面说的把问题范围缩小，降低复杂度，有利于继续剖析里面的细节。第二层含义就是集中精力办大事。DDD把子领域分为核心子领域、通用子领域、支持子领域。从字面意思就能看出重点建设的产品能力才是核心子领域，要把主要资源投入到核心领域建设。围绕核心子领域需要一些支撑性能力、通用能力。比如上面说的支付领域，往往是一种通用能力，视为通用域。还有一些是不可或缺的辅助流程，比如账号权限系统，视为支撑子领域。可以用速成的方案进行建设通用子领域和支撑子领域，比如采购现成的能力、外包服务。总之要在这个战略设计阶段规划好资源，让资源和领域匹配。

如何划分子领域？

领域的划分和后续要介绍的模块划分类似，一是从业务视角，二是从组织的视角，最后结合两个视角做一个归纳。

从业务视角划分。这是主要的划分方法。按照业务阶段分，比如上面说的购买流程就可以按照业务阶段分成不同的子领域。CRM系统可以从线索到商机、合同、成单等划分为不同的子领域。按照业务方向分，比如营销SaaS的公域流量方向和私域流量方向等。
从组织视角。根据使用目标系统的用户所在的职能进行划分。比如ERP产品就可以划分为销售、采购、仓储、财务等领域。

3个注意事项：

优先确定核心子领域。结合商业模式画布或者产品愿景、产品价值主张等内容比较容易识别出核心子领域。前面提到的MVP方法下的流程大部分应该都是核心子领域范畴。
结合承接系统的组织的职能和大小，也就是著名的康威定律。在这里的意思是说系统层面的职责划分会和现实中的组织划分趋向一致。也就是说，如果现有组织架构不太适合当前的领域划分，那么应该主动调整组织架构。
子域之间是相互独立的，没有交叉，不是包含关系。所以子域加起来就是整个领域。

2.6 识别并划分限界上下文，确定上下文间的关系

DDD的战略设计除了划分子领域，还有在子领域内继续划分限界上下文（英文名是Bounded Context，下文简称BC）。BC这个概念跟平时说的功能模块、系统、服务等概念有联系也有区别。因为BC属于业务和架构形成映射的关键节点，起到了绑定业务架构和系统架构的承上启下的作用，可以说BC是DDD的灵魂。微服务为什么需要DDD的指导很重要一点也是看重BC的划分方法论上。限于篇幅，BC相关的细节在下一篇交代。

—

结语

为什么要交代这么多产品分析和设计的内容，因为价值分析和业务流程分析的过程很重要。一方面只有这些步骤都做到位了才能对战略做出有效的拆解。另一方面这些阶段的决策依据对后续的设计和实现等战术阶段提供了非常有价值的输入和有效过渡。DDD是强调业务理解为先的，没有这些输入也就谈不上对业务的深刻理解，谈不上技术实现的合理性。

文章目录