組成場景的要素：
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在分析需求後，必須完成任務分解，也就是對職責的判別
如果分解之後的任務有太多測試用例需要編寫，則任務分解過粗，需要進行再次分解
單元測試，而應該根據領域場景進行編寫，不應針對被測方法