DDD战略2 领域知识

GitChat课程《领域驱动设计--战略篇》笔记，课程作者张逸

一.DDD开发中团队的沟通与协作

• DDD先要识别问题域，再为团队提炼达成共识的领域知识

1.理解客户需求

• 客户需求理解的三个偏差
  1）从客户那里了解到的需求并非用户最终的需求
  2）低效的沟通方式会使很小的需求理解偏差带来大相径庭的结果
  3）理解到的需求如果没有揭示完整的领域知识，将会导致领域建模与设计出现认知障碍
• 通过可视化形式的交流避免认知偏差

2.团队协作:先启阶段(Inception)

• 在项目的先启阶段，应专注宏观层面的领域知识沟通，初步建立的统一语言，在识别出史诗级故事与主要用户故事后，确定限界上下文，并搭建系统的逻辑架构与物理架构
• 具体步骤
  1）确定项目的利益相关人
  2）确定业务期望与愿景
  3）确定对问题域的共同理解
  4）确定项目的当前状态与未来状态
  5）确定项目的业务范围
  6）识别史诗级故事
  7）拆分史诗级故事为主故事列表

3.团队协作:迭代开发阶段

• 迭代计划会议
  由产品负责人(PO)向团队成员介绍和解释该迭代要完成的用户故事，包括业务逻辑与验收标准
• 每日站立会议
  由PO解答开发过程中可能出现的需求理解问题，Scrum Master通过每日站立会议了解当前的迭代进度，并基于当前进度和迭代目标确定是否需要调整需求的优先级
• 编写用户故事
  1）Kick Off:开发人员在领取用户故事后与需求分析人员和测试人员进行需求沟通与确认
  2）增量开发
  3）Desk Check:开发人员在开发环境下向需求分析人员和测试人员演示新功能，目的是快速反馈，减少沟通成本
  4）验收测试
• 迭代演示会议
  迭代结束后，由团队的测试人员向客户、最终用户以及领域专家演示迭代已经完成的功能。由于迭代周期较短，可以有效纠正因为需求理解不一致导致的功能实现偏差

迭代开发阶段

二.运用领域场景分析提炼领域知识

1.领域场景分析的6W模型

• 6W：Who，What，Why，Where，When，hoW
• 首先识别参与场景的用户角色(Who)
• 分析用户在整个场景中的活动，明确业务功能(What)和业务价值(Why)
• 对业务功能的深入分析可以确定具体的业务实现(hoW)
• 在场景建模时，还要充分考虑场景的边界(Where)，即DDD中的限界上下文(Bounded Context)

6W模型

2.领域场景的分析方法:用例(User Case)

• 思考参与系统活动的角色(参与者)，然后通过参与者的角度去思考为其提供"价值"的业务功能
• 用例规格说明(以买家下订单为例)

用例的文字描述

• 用例图

用例图

• 用例图的组成要素
  1）参与者(Actor)：Who
  2）用例(User Case)：What
  3）用例关系：包括使用、包含、扩展、特化等，其中使用(use)关系代表Why，包含和扩展的子用例都是为主用例服务，即为When与hoW
  4）边界(Boundary)：Where
• 用例之间的协作关系
  1）包含(include)：对象之间的组合关系，must have
  2）扩展(extend)：对象之间的聚合关系，nice to have

3.领域场景的分析方法:用户故事(User Story)

• 用户故事模板
  Who：As a <角色>
  What：I would like <活动>
  Why：so that <业务价值>
• 用户故事编写实例
  作为一名销售经理
  我希望为订单设置合适的配送免费的总额阈值
  以便于促进平均订单总额的提高
  验收标准
  订单总额的货币单位应以当前国家的货币为准
  订单总额阈值必须大于0
• Given-When-Then模式，通过实例化需求的方式编写用户故事
  作为⼀一名销售经理理
  我希望为订单设置合适的配送免费的总额阈值
  以便便于促进平均订单总额的提⾼高
  场景1:订单满⾜足配送免费的总额阈值
  Given:配送免费的总额阈值设置为95元⼈人⺠民币
  And:我⽬目前的购物⻋车总计90元⼈人⺠民币
  When:我将⼀一个价格为5元⼈人⺠民币的商品添加到购物⻋车
  Then:我将获得配送免费的优惠
  场景2:订单不不满⾜足配送免费的总额阈值
  Given:配送免费的总额阈值设置为95元⼈人⺠民币
  And:我⽬目前的购物⻋车总计85元⼈人⺠民币
  When:我将⼀一个价格为9元⼈人⺠民币的商品添加到购物篮
  Then:我应该被告知如果我多消费1元⼈民币，就能享受配送免费的优惠

4.领域场景的分析方法:测试驱动开发

• 测试优先的本质是需求分析优先，是任务分解优先
• 为分解的任务编写测试用例时，应根据领域场景而非被测方法编写单元测试
• 编写测试方法时，应遵循Given-When-Then模式
  1）编写Given时，思考被测对象的创建，以及它与其他对象的协作
  2）编写When时，思考被测接口的方法命名，以及它需要接收的传入参数
  3）编写Then时，思考北侧接口的返回值
• 为猜数字游戏中判断每次猜测的结果任务编写的测试方法

测试方法

三.建立统一语言

1.统一语言

• 通过提炼领域知识获得统一语言，获得统一语言是需求分析的过程，也是团队中各个角色就系统目标、范围与具体功能达成一致的过程
• 统一语言体现在
  1）统一的领域术语
  2）领域行为描述

2.统一的领域术语

• 从需求中提炼统一语言，其实就是在两个不同的语言世界中进行正确翻译的过程
• 维护领域术语表时一定要给出对应的英文术语，确保方法和类命名的一致性

3.领域行为描述

• 领域行为是对业务过程的描述，体现了更加完整的业务需求以及复杂的业务规则
• 描述领域行为时，需要满足以下要求
  1）从领域角度而非实现角度描述领域行为
  2）涉及到领域术语时，必须遵循术语表的规范
  3）强调动词的精确性，符合业务动作在该领域的合理性
  4）要突出与领域行为有关的领域概念