在软件构建过程中，要正确认识领域。一种形象的方式就是通过“场景”来展示领域逻辑。领域专家或业务分析师从领域中提取“场景”，就像从一个抽象的三维球体中切割出具体可见的一块。再以此场景为舞台，上演各个人物之间的悲欢离合。每个角色的行为都是在业务流程的指导下进行的，并受到业务规则的约束。当我们描述一个场景时，就好像我们在讲一个故事，就好像我们在拍一部电影。构成场景的元素通常被称为6W模型，即描述场景的过程必须包括Who、What、Why、Where、When和hoW这六个元素。6W模型如下图所示：在通过场景分析领域需求时，我们需要首先识别参与场景的用户角色。我们可以为它建立一个用户画像（Persona），通过分析用户的特征和属性，识别角色在整个场景中参与的活动。这意味着我们需要明确业务功能（what），思考这个功能能给角色带来什么业务价值（why）。注意，这里所谓的“角色”是多态的，同一个用户在不同场景下可能扮演完全不同的角色。例如，在电子商务系统中，如果执行下订单的功能，则角色是买家；如果对订单进行了评论，则参与角色将成为审阅者。在6W模型中，我将领域功能分为三个层次，即业务价值、业务功能和业务实现，我称之为“职责层次”。定义为“责任（Responsibility）”，是为了更好地体现它与角色的关系，即“角色履行职责”。商业价值体现了职责存在的目的，即解释了该领域的需求Why。只有提供了责任，场景才对参与角色有价值。为了满足业务价值，我们可以进一步分析需要哪些支持功能来实现价值。这些业务功能对应于6W模型中的What。进一步，我们可以通过对功能的深入分析，分析得出具体的业务实现。业务实现关注的是如何实现业务价值，从而对应于如何实现。在电子商务系统中购买商品时，下订单的责任对买家来说具有商业价值。通过领域分析，结合职责层次概念，我们可以得到如下职责层次结构：下订单验证订单是否有效验证订单是否为空验证订单信息是否完整验证当前状态是否正确订单处于“待提交”状态验证订单提交者是否为合法用户验证商品库存是否大于或等于订单数量根据计算订单总价、折扣和运费关于业务规则获取用户信息获取当前促销规则计算订单总价计算订单折扣计算产品运费提交订单将是将订单商品插入数据表将订单插入数据表更新订单状态为“待付款”更新购物车删除购物车中的相应产品发送一个通知买家发送邮件通知订单提交成功并等待付款当我们获得这样的职责层次可以帮助我们更详细地对领域进行建模。在使用场景进行建模时，还需要充分考虑场景的边界，即6W模型中的Where。比如“下单”，验证商品库存的业务实现需要调用库存提供的接口，但这个功能实际上在下单场景的边界之外。领域驱动设计引入了限界上下文（BoundedContext）来解决这个问题。为问题领域提取领域知识是一个空洞的概念。业务场景分析的6W模型提供了指导约束，要求我们抽取领域知识必须具备模型的六大要素。这就像两个雄辩的喋喋不休。因为有明确的主题和话题边界，原本漫无目的的闲鹤闲云，变成了交流深入的高端话题对话。6W模型也是对领域逻辑的考验。如果提取的领域逻辑缺少某些元素，则可能会忽略一些重要的领域概念、规则和约束。这种缺失将对后续的领域建模产生直接影响。追根究底，按照领域场景分析的6W模型分析领域逻辑，提炼领域知识，从一开始就能在一定程度上保证领域模型的完整性。【本文为专栏作家“张艺”原创稿件，转载请联系原作者】点此阅读更多该作者好文
