在软件构造过程中，我们必须正确地理解领域。一种生动的方式是通过“场景”来展现领域逻辑。领域专家或业务分析师从领域中提炼出“场景”，就好像是从抽象的三维球体中，切割出具体可见的一片。然后以这一片场景为舞台，上演各种角色之间的悲欢离合。每个角色的行为皆在业务流程的指引下展开活动，并受到业务规则的约束。当我们在描述场景时，就好像在讲故事，又好似在拍电影。
组成场景的要素常常被称之为6W模型，即描写场景的过程必须包含Who，What，Why，Where，When与hoW这六个要素。6W模型如下图所示：
通过场景分析领域需求时，我们需要首先识别参与该场景的用户角色。我们可以为其建立用户画像(Persona)，通过分析该用户的特征与属性辨别该角色在整个场景中参与的活动。这意味着我们需要明确业务功能(what)，思考这一功能给该角色能够带来什么样的业务价值(why)。注意，这里所谓的“角色”是参差多态的，同一个用户在不同场景可能是完全不同的角色。例如在电商系统中，倘若执行的是下订单功能，则角色就是买家;针对该订单发表评论，参与的角色就变成了评论者。
在6W模型中，我将领域功能划分为三个层次，即业务价值、业务功能和业务实现，我将其称之为“职责的层次”。定义为“职责(Responsibility)”，才能够更好地体现它与角色之间的关系，即“角色履行了职责”。业务价值体现了职责存在的目的，即解释了该领域需求的Why。只有提供了该职责，这个场景对于参与角色才是有价值的。为了满足业务价值，我们可以进一步剖析为了实现该价值需要哪些支撑功能，这些业务功能对应6W模型中的What。进一步，我们对功能深入分析，就可以分析获得具体的业务实现。业务实现关注于如何去实现该业务价值，因而对应于hoW。
在电商系统中购买商品时，对于买家而言，下订单这一职责是具有业务价值的。通过领域分析，结合职责的层次概念，我们就可以得到如下的职责分层结构：
下订单
- 验证订单是否有效
- 验证订单是否为空
- 验证订单信息是否完整
- 验证订单当前状态是否处于“待提交”状态
- 验证订单提交者是否为合法用户
- 验证商品库存量是否大于等于订单中的数量
基于业务规则计算订单总价、优惠与配送费
- 获取用户信息
- 获取当前促销规则
- 计算订单总价
- 计算订单优惠
- 计算商品配送费
提交订单
- 将订单项插入到数据表中
- 将订单插入到数据表中
- 更新订单状态为“待付款”
更新购物车
- 删除购物车中对应的商品
发送通知
- 给买家发送电子邮件，通知订单提交成功，等待付款
当我们获得这样的职责层次结构之后，就可以帮助我们更加细致地针对领域进行建模。在利用场景进行建模时，还要充分考虑场景的边界，即6W模型中的Where。例如在“下订单”的案例中，验证商品库存量的业务实现需要调用库存提供的接口，而该功能实则属于下订单场景的边界之外。领域驱动设计引入了限界上下文(Bounded Context)来解决这一问题。
针对问题域提炼领域知识是一个空泛的概念，业务场景分析的6W模型给出了具有指导意义的约束，要求我们提炼的领域知识必须具备模型的六个要素。这就好比两位侃侃而谈的交谈者，因为有了确定的主题与话题边界，一场本来是漫无目的野鹤闲云似的闲聊就变成了一次深度交流的专题高端对话。6W模型也是对领域逻辑的一种检验，如果提炼出来的领域逻辑缺乏部分要素，就有可能忽略一些重要的领域概念、规则与约束。这种缺失会对后续的领域建模直接产生影响。正本清源，按照领域场景分析的6W模型去分析领域逻辑，提炼领域知识，可以从一开始在一定程度上保证领域模型的完整性。
【本文为51CTO专栏作者“张逸”原创稿件，转载请联系原作者】
