组成场景的要素：
6W模型：
Who：用户
、
What：业务功能
、
Why： 业务价值
、
Where：domain
、
When：应用层对domain层调用的时序
、
How：业务实现
领域场景分析
前提：
识别参与该场景的用户角色（WHO）
业务功能（What）：分析该用户 特征属性 辨别其在在整个场景中参与的活动（如订单系统 用户只参与了下单）
业务价值（WHY）：这一功能给该用户角色带来什么样的好处
通过领域分析，结合职责的层次概念，我们就可以得到如下的职责分层结构：
下订单
-
验证订单是否有效
-
验证订单是否为空
-
验证订单信息是否完整
-
验证订单当前状态是否处于“待提交”状态
-
验证订单提交者是否为合法用户
-
验证商品库存量是否大于等于订单中的数量
-
-
基于业务规则计算订单总价、优惠与配送费
-
获取用户信息
-
获取当前促销规则
-
计算订单总价
-
计算订单优惠
-
计算商品配送费
-
-
提交订单
-
将订单项插入到数据表中
-
将订单插入到数据表中
-
更新订单状态为“待付款”
-
-
更新购物车
-
删除购物车中对应的商品
-
-
发送通知
-
给买家发送电子邮件，通知订单提交成功，等待付款
-
职责分层结构可以使我们更加细致地针对领域进行建模
建模时需要考虑边界（WHERE）：如在『下订单』案例中，验证商品库存量的业务实现 需要调用库存提供的接口，该功能室下订单场景的边界之外 使用限界上下文来解决此问题。
场景分析模式：
用例（USE CASE）
用户故事（USE STORY）
测试驱动开发（TEST DRIVEN DEVELOPMENT）
用例：
组成用例图的要素：
WHO
WHAT
WHY
WHERE（如上图中清除购物车中物品 不在下订单领域中 如上图中 用例间协作关系的extend）
用例之间协作关系：
1 包含（include）
2 扩展（extend）
包含扩展的区别：
包含：子用例是主用例中必须的一个执行步骤
扩展：子用例是对主用例的一种补充或强化，即便没有该用例 对主用例也不会产生影响（清除购物车失败 不会对下订单造成影响）
用户故事：
一种经典的用户故事模板：
As a（作为）<角色>
I would like（我希望）<活动>
so that（以便于）<业务价值>
作为一名项目成员，
我希望获取分配给自己的未完成任务，
以便于跟踪自己的工作进度。
Given-When-Then 模式，并通过实例化需求的方式编写用户故事：
作为一名销售经理
我希望为订单设置合适的配送免费的总额阈值
以便于促进平均订单总额的提高
场景1：订单满足配送免费的总额阈值
Given：配送免费的总额阈值设置为95元人民币
And：我目前的购物车总计90元人民币
When：我将一个价格为5元人民币的商品添加到购物车
Then：我将获得配送免费的优惠
场景2：订单不满足配送免费的总额阈值
Given：配送免费的总额阈值设置为95元人民币
And：我目前的购物车总计85元人民币
When：我将一个价格为9元人民币的商品添加到购物篮
Then：我应该被告知如果我多消费1元人民币，就能享受配送免费的优惠
编写“发送邮件”这个业务场景的用户故事（用户故事是从业务角度触发，不会暴露技术细节 应该关注于做什么（WHAT 业务功能） 而不是怎么做（HOW 业务实现））：
如错误的示例：
代码块
Java
Scenario: send email
Given a user "James" with password "123456"
And I sign in
And I fill in "[email protected]" in "to" textbox
And fill in "test email" in "subject" textbox
And fill in "This is a test email" in "body" textarea
When I click the "send email" button
Then the email should be sent sucessfully
And shown with message "the email is sent sucessfully"
业务建模阶段，业务才是重点，而不是技术实现
专注领域行为的形式编写：
代码块
Java
Scenario: send email
Given a user "James" with password "123456"
And I sign in
And I fill in a subject with "test email"
And a body with "This is a test email"
When I send the email to "Mike" with address "[email protected]"
Then the email should be sent sucessfully
TDD：测试驱动开发：
需求分析优先：任务分解优先
RD在分析需求后，必须完成任务分解，也就是对职责的判别
如果分解之后的任务有太多测试用例需要编写，则任务分解过粗，需要进行再次分解
单元测试，而应该根据领域场景进行编写，不应针对被测方法
