上一篇讲了DDD的主要流程，包含了先启阶段，战略战术设计及迭代优化，本篇将详细讲述先启阶段的各个步骤

一、此阶段的目的

通过此阶段，需要让项目参与者和客户之间，就项目本身达成一些共识，并且形成统一语言，便于后续的沟通确认。
此阶段是非常重要的，里面达到的一些共识，有助于在后期我们判断某些功能是否需要实现，实现的优先级，以及对整体架构的选择都会产生影响

二、步骤

1. 确定利益相关人

提前与项目需求方确定项目的利益相关人，以便后续在的流程中，根据需要寻找相应的利益相关人一起参与讨论

2. 制订先启计划

主要是提供一个计划，什么时候与哪些利益相关人讨论哪些主题，比如下面的表格

3. 确定业务期望与愿景

可通过回答以下问题，来进行业务期望与愿景的讨论和确定
为了XXX目标用户，他们的XXX痛点，这个XXX系统，是一个XXX系统基本定位，它可以提供XXX功能点，而不像XXX竞品，我们的产品拥有XXX核心竞争力
比如，我们的云游艇的产品愿景截图如下：

4.优先级权衡

在面对客户提出的源源不断的需求时，我们的资源和时间是有限的，所以需要对这些需求按一定的规则进行确定优先级。
如果是业务的，可以根据业务需求与产品愿景的关联程度来确定。
如果是其他方面的，则需要提前与用户约定好一般原则，比如是在资源不变的情况下，尽量保证进度，可以牺牲一定的质量。还是在保证进度和质量的前提下，可以适当增加成本，用户愿意承担这个成本等。
一种比较好的实践是采用所谓的价值滑条（Value Slider），即基于该需求协商谈判的可能性高低，步骤如下：

1. 列出所有的质量属性需求与管理需求，由客户来做出判断。
2. 给出一个协商度的划分，从不可协商到可协商进行分级，级数等于列出的质量属性与管理需求的数量
3. 在商讨每一个需求，确定协商度分级时，不能出现两个及以上的需求的分级程度相同
4. 循环针对每一个需求，与用户进行沟通确认此需求的协商度分级
   1. 若协商谈判的可能性高，则说明该需要是可以协商的，可以做出让步的
   2. 若协商谈判的可能性低，就说明不可商量，没有妥协的余地，必须满足 | 需求 | 协商度（不可协商：5，可协商：1） | | —- | —- | | 进度 | 5 | | 可用性 | 4 | | 质量 | 3 | | 成本 | 2 | | 完成的功能 | 1 |

从上面的这个示例中可以看出，必须保证进度，为了保证进度，可以将一些功能放到二期，并且可以适度的增加人力成本来保证进度。

5.对问题域的共同理解

5.1. 子域划分和确定

通过与用户沟通确认，为了实现之前确定的业务期望与愿景，一共需要哪些业务模块来支撑整个业务，这些业务模块与业务期望愿景的重要程度是如何的，将整个业务领域划分为不同的子域，并且根据子域的业务价值来确定是核心子域，支撑子域还是通用子域。并且根据子域的重要程度配置不同力量的开发团队，甚至将一些通用子域可考虑通过外包或者直接采购开源软件等方式来实现。
比如上面的云游艇项目，可以划分为会员子域，游艇子域，出海子域，泊位子域，客账子域，支付子域等。其中的核心子域有：出海子域和泊位子域，支撑子域有：游艇子域，客账子域，而通用子域有会员子域，支付子域。
这些子域的划分和其业务价值的重要度，是需要和用户达成共识的。

5.2. 统一语言的建立

针对每个子域的名称，以及子域内的核心概念都需要和用户统一，形成统一语言。比如会员，游艇，船长，水手，泊位，出租类型等，并且每一个概念都要有对应的英文名称（主要用于和代码对应），并且在平时的沟通过程中，描述业务场景或者沟通需求时，都要使用这些统一语言元素来描述和沟通。
随着业务的发展，统一语言也是需要不断发展和完善的，可能会有新的概念补充进来，可能会有一些过时的概念需要从统一语言和代码中移除。
形成统一语言时，特别要注意的是同一概念的岐义，即一个概念名称有多个含义，如果出现这种情况，则说明需要对这一概念进行进一步的划分，将他归类到不同的子域中，确保一个子域中，一个概念名称只能有一个含义。

6.确定项目的业务范围

通过和客户对问题域的分解，会发现有些子域中的功能是需要与其他现有系统或者第三方进行对接的，而有些是全新的，需要全部自行实现的，而业务范围就是需要确定这样一个范围：

1. 需要实现的系统有哪些使用者
2. 需要实现的系统拥有哪些业务功能模块
3. 需要实现的系统需要与哪些现有系统或第三方进行对接
4. 比如，我们这次要新实现的捷信达旅游管理系统的系统边界图如下：

7.确定业务流程

需要与用户确定一个流程，用于将所有功能模块串联起来，以实现最终的业务期望和愿景。
在此阶段确定的流程是一个比较粗的业务流程，需要考虑的是流程背后的需求，而不是现有流程的简单实现。因为现有流程只是用户现阶段的管理流程，而此流程可能变化比较大，比如随着业务的复杂，分工越细，则需要更细化的流程来支撑业务。如果我们一开始就能分析出，整个业务流程的这些背后的角色需要，而据此形成业务流程，就不太容易变更。只是现阶段有些人身兼多个角色，而将来会由不同的人来承担而已。
比如酒店的主体流程：
客人预订》客人到达》接待办理入住》收银收取押金》客人入房》房务打扫》客人退房》收银结账》房务打扫
其中接待办理入住可能和收取押金有些酒店是合在一起办理的，有的是分开的，所以我们就不能只是根据酒店现在的流程是合并还是分开来考虑，而是要考虑各自的角色和作用，比如接待是由角色前台接待员操作，主要作用是进行客人资料的登记。而收取押金是由角色收银员进行操作，主要作用是根据酒店政策，计算出应收取押金金额，并且完成押金收取动作等。这样只是在有的酒店是同一人担任了两个角色，而有的酒店是一人担任一个角色。在同一人担任了两个角色时，可以考虑前端界面上做一些合并，但是对于业务领域来说是不用调整修改的。

此篇介绍了在项目启动前，需要通过一些步骤和用户达成一些共识和原则，并且理清项目的业务期望和边界，为接下来的战略设计做准备。那么战略设计又是什么，有哪些基本步骤或方法呢？点击传送门前往。