iT邦幫忙

2021 iThome 鐵人賽

4
Software Development

系統與服務雜談系列 第 32

Domain Storytelling - 簡單的方法說出一個Domain story

上篇回顧
Story Telling - 簡易有效的討論
講到會議很煩很冗長沒重點還要開好幾次, 是因為一開始大家都不熟問題域, 甚至連對問題的認知都有顯著的落差
講到說故事可以讓聽者快速了解流程
講到敏捷宣言裡鼓勵互動與協作
Slide - Slide - Storytelling & Domain Stroytelling

Cost of Change Curve

上一篇講到敏捷開發宣言
這裡看一下Waterfall, TDD, Agile, 各自當面臨需求變更或錯誤所需要的修復成本
Examining the Agile Cost of Change Curve

Waterfall

https://ithelp.ithome.com.tw/upload/images/20211031/20104930ivauDJsuaZ.png

TDD

https://ithelp.ithome.com.tw/upload/images/20211031/20104930Ib4TtHoYrt.png
在開發前, 先寫Test, 來設計與開發軟體

Agile

Reduce the feedback cycle
https://ithelp.ithome.com.tw/upload/images/20211031/20104930RxWVSxmR6h.png
Agile這裡有兩種顏色, Green與Red
Red是成本相對高的作法或是文化習慣
Green則是相對低的成本

透過Model Storming(DDD的Domain storytelling, event storming or other medeling methods...),
可以減少設計或是需求梳理理解上的錯誤

透過跟跟Stackholder的協作互動, 可以減少設計或是需求梳理理解上的錯誤
https://ithelp.ithome.com.tw/upload/images/20211031/20104930t4TwBHIJQb.png

其實後兩個都是在不同階段, 提早發現問題, 及早Feedback
浪費往往就是在後期才發現, 如果能盡量消弭浪費, 則能相對於以前
面對變化與錯誤時是敏捷的

But!
如果公司也沒覺得自己的Waterfall有什麼浪費的話, 也硬要改變的必要就是了

What is Domain?

https://ithelp.ithome.com.tw/upload/images/20211031/20104930NaD6gpL4Po.png
DDD的作者Eric Evan提出對於Domain的定義是

A sphere of knowledge, influence, or activity.
The subject area to which the user applies a program is the domain of the software

其中一個字sphereOX Dictionary這樣描述的
https://ithelp.ithome.com.tw/upload/images/20211031/20104930Pt614RZ8GD.png
跟Eric Evan描述的維度幾乎一樣吧XD 且同義字就是Domain

knowledge, influence, or activity
用戶圍繞在這三個主題的範疇上, 怎應用你的軟體來滿足用戶
用戶為了執行某些行為, 需要這軟體的支持
為了滿足用戶需求, 需要這軟體的支持

用Domain Storytelling來說Waterfall的流程

不搭配文字描述, 我是覺得不難看得懂, 因為這應該要我用講的搭配畫面播放XD

https://ithelp.ithome.com.tw/upload/images/20211031/20104930LVXnCElCrF.png
https://ithelp.ithome.com.tw/upload/images/20211031/20104930IL3CwFuUid.png
https://ithelp.ithome.com.tw/upload/images/20211031/201049306vRvQEJYrz.png
https://ithelp.ithome.com.tw/upload/images/20211031/201049308VJnmMj2go.png

用Domain Storytelling來說Stakeholder參與協作的流程

https://ithelp.ithome.com.tw/upload/images/20211031/20104930LVXnCElCrF.png
https://ithelp.ithome.com.tw/upload/images/20211031/20104930TxC6FzlrHL.png
https://ithelp.ithome.com.tw/upload/images/20211031/20104930HRvx1FdqgU.png
https://ithelp.ithome.com.tw/upload/images/20211031/20104930MzUTLIXJW7.png
https://ithelp.ithome.com.tw/upload/images/20211031/20104930m1Aox5RhHY.png
https://ithelp.ithome.com.tw/upload/images/20211031/20104930qHmfDaLBE0.png
https://ithelp.ithome.com.tw/upload/images/20211031/20104930K437w8X6sF.png

差別就只是先請規劃者來說個故事給開發者們聽,
當下開發者們快速的畫出這樣的業務流程
同時請規劃者也閱讀並協作修正

是這裡提倡的提早把認知跟規劃者一起協作交互溝通,
讓彼此對業務流程和問題的認知拉其的一種方法跟介入的時機點

Benefits for Telling Storeis 與 Visualize Business Flow

https://ithelp.ithome.com.tw/upload/images/20211031/20104930sWdigmb6pI.png
Designer針對它所需要理解的Domain範疇可能只是一部份,
他們可以快速假設出Prototype來驗證

Q: 開發人員所需要的Domain就剛好跟Designer認知的範疇一模一樣嘛?
Q: 但開發軟體呢? 如何早點的把假設的部份給具現化來討論並驗證?
https://ithelp.ithome.com.tw/upload/images/20211031/20104930mN2T65HZ87.jpg

快速的給出一些Telling Storeis 與 Visualize Business Flow的好處
https://ithelp.ithome.com.tw/upload/images/20211031/20104930dce3FHvKxj.png
我懶得細細描述, 這些是出自Domain Storytelling這本書的第一小節

Domain Storytelling

https://ithelp.ithome.com.tw/upload/images/20211031/20104930UVrSohmTvK.png
一種協作建模的工具
目的讓來自不同背景的與會人員, 能透過可視化的故事跟說故事的方式學習彼此的領域範疇

Pictorgraphic Language

進到書本的第二章了, 主要講這畫布上的內容與文法
https://ithelp.ithome.com.tw/upload/images/20211031/20104930MScwEZe0sI.png
主要就

  • Actor
    • 一個句子裡的主詞
    • 可以是人、一群人、一個系統、一個外部服務
  • Work Object
    • 通常是一個句子裡的受詞
    • 也可能是Actor之間戶通有無的東西
    • 可以是實體的事物、虛擬的事物、甚至只是一些資訊, 說故事不會特別地去區別它們(數據,事物還是資訊)
  • Activity
    • 通常是一個句子內的動詞, 剛剛的Actor跟Work Object 都是名詞
    • 具有方向性, 指向接收方
  • Sequence Number
    • 標示在Activity上的數字
    • 一個故事中會有一堆句子, 這數字用來表示故事裡的句子順序而已
    • 舉例: 7號句子, 會在6號句子後面被講出來(不是廢話嘛? 對就是這麼廢話, 但這數字讓人方便了解前後文的關聯方向)
  • Annotation
    • 任何你想補充的資訊
    • 該Actor/WorkOjbect的狀態
    • 條件表達等等的, 任何想講的都能寫在這
    • 或者對這Activity想做的補充
    • 別寫散文在這就好

蠻多元素跟UML的Sequence Diagram類似

Grammar- 故事中句子的表示法

https://ithelp.ithome.com.tw/upload/images/20211031/20104930iYEP5NVdtX.png
其實文法不多, 學習門檻非常的低

Avoid Grammar

https://ithelp.ithome.com.tw/upload/images/20211031/20104930l5ov9RA1hT.png

  • Loopbacks
    • 這不是在描述API
    • User做出動作, 本來就是期望會得到預期的資訊, 我們更在意的是業務流程
  • Conditional

Domain Storytelling to User Story

https://ithelp.ithome.com.tw/upload/images/20211031/20104930VyJT4xyZQO.png
常常我們做產品都會用UserStory來描述問題與需求

這裡只是快速講怎轉換語法,
但怎從Domain storytelling慢慢的拆解映射到User story mapping
就實戰工作坊比較合適講解了

Domain Storytelling轉換Pictorgraphic Language到User Story

https://ithelp.ithome.com.tw/upload/images/20211031/20104930lpHPHuzncF.png
https://ithelp.ithome.com.tw/upload/images/20211031/20104930FPjMGgAWI5.png

大致上到這裡Domain Storytelling故事就講完了
軟體設計要怎進行?
我想才是大家的疑惑!

流程大概是, 從故事的流程中, 針對上面的角色,流程方向, 事物用途, 來設計出適當的邊界
https://ithelp.ithome.com.tw/upload/images/20211031/20104930LUHltUsRre.png
然後每個邊界在Zoom In繼續分析討論, 但這時也許就能分工出去給各組去討論了
嘗試在這邊界的場景內,找出sub-domain跟aggregate
https://ithelp.ithome.com.tw/upload/images/20211031/20104930Fdlju5Qp4p.png

再來就能各小組來玩User Story Mapping
找出有價值或是優先權高的story跟拆分出task

再來各組搭配Example mapping
https://ithelp.ithome.com.tw/upload/images/20211031/20104930ygGGoSYwsT.png
根據規格Rule(規格書通常會給), 假設出情境並給出期望的答案
這裡的展開內容, 可以做整合測試, UnitTest
甚至如果是用Gherkin語法, 還能轉成BDD所需要的測試案例

OO Analysis & Design

https://ithelp.ithome.com.tw/upload/images/20211031/20104930oVdOEmTk8f.png
OOAD 拆成Analysis 跟Design
OOA, 來辨識What to do?
OOD, 辨識出要做什麼後, How to do?

流程也是非常雷同的, Divide & Conquer 然後持續repeat細化精化
把ProblemSpace給拆解梳理的過程就是Project(投射)到Requirement Layer(各位開發者最愛談的分層設計?)
都梳理好了分析好了, 再來投射到Design, 開始設計
最後都設計好了有規格書跟TableSchema還有UI了!? 開始寫扣, 投射到Implement
最後佈署發布
每一層其實都有其驗收條件, 不然就又要最後上線給QA背鍋去了XD

工作了快10年, 合作過不少PM/SA都說很會做軟體設計, 我是沒看到UML圖做分析設計
幾乎都看到UI Prototype + Table Schema + 數十頁的文字檔 + 人月工時都估算好了

但每次開會我問, 各層的驗收條件是什麼? 都傻住, 講不出來QQ
通常當下回應我的內容是我們這次的系統沒那麼複雜, 都是CRUD
等日後QA跑去問測試案例, 常得到的回答是我也沒辦法從畫面跟資料庫推斷出流程
(當然阿 你當初設計就沒把這些給寫下來或視覺化, 日後問時, 人都會忘XD)

我: ...真的要開發人員腦補就是了XD
QA: 暗, 只好慢慢地探索性測試

如果真有公司這樣子跑流程, 但嘴裡喊著敏捷, 我應該會覺得很困惑QQ
無形中一堆浪費, 但沒改善
可能只是想壓榨完成的時間吧

也非常多公司, 軟體/系統設計, Table Schema+API Doc都是PM/SA寫的.
開發人員都真的是按表操課, 等後面的新同事來了, 前輩&後輩也只能腦補, 因為都是對於文件的想像

右半邊的圖是OOAD的流程, 但我懶得細說了, 沒驗收條件什麼都假的QQ
都是把責任往QA跟使用者拋
https://ithelp.ithome.com.tw/upload/images/20211031/20104930WCOfd172tv.jpg

有人常講以終為始, 我覺得用什麼角度解讀這句. 有人以User在想, 有人以資料流在想,

但我身為開發人員, 我更喜歡以中為始,
中間那層業務邏輯, 應該是不變得, 這的不變不是業務流程真的都不會變
而是它不應該因為資料庫變動, API協議變動, 畫面變動, 而影響到業務
相對於外部環境, 我們的領域與業務不應該受到外部環境影響而被影響
一定要有測試保護的也是這層
都只講UI+TableSchema, 也難怪這樣的公司幾乎沒在寫測試.
因為開發團隊一定問, 要測試什麼? 都在資料庫裡阿, 不就CRUD
都只講UI+TableSchema, 就一定開會時爭執這些細節XD

More Thinking

https://ithelp.ithome.com.tw/upload/images/20211031/20104930EfvGRXg2Wz.png

Reference

DST範例下載,至Modeler做Import就可, 內容是JSON格式可以進Git做版控XD

ps. Domain Storytelling是本淺顯易懂的好書, 有讀書會開團跑工作坊嘛QQ


上一篇
Story Telling - 簡易有效的討論
系列文
系統與服務雜談32

2 則留言

1
json_liang
iT邦新手 4 級 ‧ 2021-10-31 23:35:45

恭喜完賽 有機會開workshop嗎

雷N iT邦新手 1 級 ‧ 2021-10-31 23:45:15 檢舉

我等哥的Workshop

1
whitefloor
iT邦新手 3 級 ‧ 2021-11-02 15:01:54

不會畫UML跟寫測試真的是一箭殺死不知道多少自稱資深工程師的

還遇過資深工程師說把repo拆開寫很難trace

顆顆

雷N iT邦新手 1 級 ‧ 2021-11-02 15:12:04 檢舉

不會很難trace阿,
可能都只想要交給DB
幫忙做完, repo純粹拿view model XD
然後就會質疑, 都model是要測試什麼? 疑

滿滿的即視感

我要留言

立即登入留言