领域场景分析的6W模型

在软件构造过程中，我们必须正确地理解领域。一种生动的方式是通过“场景”来展现领域逻辑。领域专家或业务分析师从领域中提炼出“场景”，就好像是从抽象的三维球体中，切割出具体可见的一片。然后以这一片场景为舞台，上演各种角色之间的悲欢离合。每个角色的行为皆在业务流程的指引下展开活动，并受到业务规则的约束。当我们在描述场景时，就好像在讲故事，又好似在拍电影。

组成场景的要素常常被称之为 6W模型 ，即描写场景的过程必须包含 W ho， W hat， W hy， W here， W hen与ho W 这六个要素。6W模型如下图所示：

通过场景分析领域需求时，我们需要首先识别参与该场景的用户角色。我们可以为其建立用户画像（Persona），通过分析该用户的特征与属性辨别该角色在整个场景中参与的活动。这意味着我们需要明确业务功能（what），思考这一功能给该角色能够带来什么样的业务价值（why）。注意，这里所谓的“角色”是参差多态的，同一个用户在不同场景可能是完全不同的角色。例如在电商系统中，倘若执行的是下订单功能，则角色就是买家；针对该订单发表评论，参与的角色就变成了评论者。

在6W模型中，我将领域功能划分为三个层次，即业务价值、业务功能和业务实现，我将其称之为“职责的层次”。定义为“职责（Responsibility）”，才能够更好地体现它与角色之间的关系，即“角色履行了职责”。业务价值体现了职责存在的目的，即解释了该领域需求的Why。只有提供了该职责，这个场景对于参与角色才是有价值的。为了满足业务价值，我们可以进一步剖析为了实现该价值需要哪些支撑功能，这些业务功能对应6W模型中的What。进一步，我们对功能深入分析，就可以分析获得具体的业务实现。业务实现关注于如何去实现该业务价值，因而对应于hoW。

在电商系统中购买商品时，对于买家而言， 下订单 这一职责是具有业务价值的。通过领域分析，结合职责的层次概念，我们就可以得到如下的职责分层结构：

• 下订单

• 验证订单是否有效

• 验证订单是否为空

• 验证订单信息是否完整

• 验证订单当前状态是否处于“待提交”状态

• 验证订单提交者是否为合法用户

• 验证商品库存量是否大于等于订单中的数量

• 基于业务规则计算订单总价、优惠与配送费

• 获取用户信息

• 获取当前促销规则

• 计算订单总价

• 计算订单优惠

• 计算商品配送费

• 提交订单

• 将订单项插入到数据表中

• 将订单插入到数据表中

• 更新订单状态为“待付款”

• 更新购物车

• 删除购物车中对应的商品

• 发送通知

• 给买家发送电子邮件，通知订单提交成功，等待付款

当我们获得这样的职责层次结构之后，就可以帮助我们更加细致地针对领域进行建模。在利用场景进行建模时，还要充分考虑场景的边界，即6W模型中的Where。例如在“下订单”的案例中，验证商品库存量的业务实现需要调用库存提供的接口，而该功能实则属于下订单场景的边界之外。领域驱动设计引入了 限界上下文（Bounded Context） 来解决这一问题。