※ 本文為 dinos 轉寄自 ptt.cc 更新時間: 2018-06-12 16:26:02
看板 Soft_Job
作者 標題 Re: [請益] Domain-driven design 推薦書
時間 Tue Jun 12 15:48:36 2018
參考下個人於 10年前所介紹的一本書：Object Models — Strategies, Patterns, and Applications
http://www.kenming.idv.tw/ithome_a_cec_a_12_object_models_a_strate/
{iThome 書評—12} Object Models — Strategies, Patterns, and Applications | Kenmingの鮮思維 副標題：懂得從各問題領域的表象中跳脫，而能直指其核心的本質，才是軟體結構分析的根本所在！！ Object Models — Strategies, Patterns, and Applications ----------------------------------- 作者／Peter Coad ...
其中所揭露的 Transaction Pattern，即為跨 Domain-nature 非常受用的分析技術，藉此得以捕捉系統的主結構。
底下是原個人的書評心得介紹。
一、直指企業核心的本質—交易樣式：
本書主要的作者為 Peter Coad，最早研究所教科用書，有許多就是採用他的著作：“
Object Oriented Analysis、Design ”兩本經典 OO 著作；不過軟體人員對他仍很陌生
，那麼說出 Borland Together，就會恍然大悟，原來就是他創立的公司研發的主力產品
(後被 Borland 花了兩億美金併購)。
，那麼說出 Borland Together，就會恍然大悟，原來就是他創立的公司研發的主力產品
(後被 Borland 花了兩億美金併購)。
先讓讀者瞭解一下，結構分析主要就是抓各領域的穩定元素來建構軟體系統，而那往往就
是常在溝通的概念術語 (concept terminology)。在設計階段一般是以 UML 類別圖
(class diagram) 來呈現，而具體化在應用系統中的就是所謂的企業物件 (business
object)；與在資料庫的表格 (table)。兩者的差別主要在於企業物件尚需分析各個物件
所應負擔的責任 (在程式語言則稱之為 方法, method)。分析領域物件與明確分派物件的
責任，正是影響軟體結構彈性度的主要關鍵。
所應負擔的責任 (在程式語言則稱之為 方法, method)。分析領域物件與明確分派物件的
責任，正是影響軟體結構彈性度的主要關鍵。
有別於絕大部分 SA/SD 是透過需求訪談記錄一個一個的抓“名詞”，雖然是行之有年，
但那實在不是一種好方法，所抓出來的類別往往見樹不見林，無法有效的將相關的類別關
連於一起。 Peter Coad 是直接直指領域核心，觀察企業行為的本質源自於交易。交易為
商業利益交換的一種契約 (contract)，是一種非常必要保存的事件 (event)記錄，再由
此為中心，來串連其它相關類別包括 參與者 (actor)，地點 (place)，物品 (item)，以
及所包含的交易細項 (line-item) 等。這種先抓主幹，再抓枝葉的方式，正是相當著名
由 Peter Coad 所揭露的 “交易樣式 (transaction pattern)”。
但那實在不是一種好方法，所抓出來的類別往往見樹不見林，無法有效的將相關的類別關
連於一起。 Peter Coad 是直接直指領域核心，觀察企業行為的本質源自於交易。交易為
商業利益交換的一種契約 (contract)，是一種非常必要保存的事件 (event)記錄，再由
此為中心，來串連其它相關類別包括 參與者 (actor)，地點 (place)，物品 (item)，以
及所包含的交易細項 (line-item) 等。這種先抓主幹，再抓枝葉的方式，正是相當著名
由 Peter Coad 所揭露的 “交易樣式 (transaction pattern)”。
以最常見的訂購系統來說好了，“訂購(order)”就是核心的交易類別，再由其串連出來
，就可以找出“訂購細項(transaction lineitem)”、“客戶(actor)”、“訂購地點
(place)”、“商品項目(item)”等；再轉分析另一個領域如保險業，“保險”絕對是一
個顯而易見的交易類別，而“對保”則是與之有相關連後續的交易類別 (subsequent
transaction class)；好啦，如果是要分析一個運動彩券投注系統，要你馬上抓出第一個
類別，應該就知道該怎麼抓吧？ (投注, 派彩 均為該領域的核心類別)
二、不同層次，傳不同層次的法：
我是從 amazon 購買 a4-size 的硬本精裝版，本書可是有著四顆半星的高評價，讀者對
之推崇甚高。封面為樂高玩具，甚是有趣，看起來其隱喻應該是意指軟體的結構組成，就
如同樂高積木般，一個個地給聚合組裝起來的。共有七個章節，前五章均為各自獨立的案
例分析，後兩章為策略與樣式的整理列表。印刷很不錯，字體大小恰當且清晰，也有很豐
富有趣的插圖。不過內容可是相當艱深，沒有充分的抽象與想像力，是不容易理解的。獨
立閱讀本書可說是非常吃力，我是建議能有幾位同好們一起研讀，甚至以角色扮演的方式
，來思考所抓出來的類別，以及所賦予其責任的合理性與正確性。
之推崇甚高。封面為樂高玩具，甚是有趣，看起來其隱喻應該是意指軟體的結構組成，就
如同樂高積木般，一個個地給聚合組裝起來的。共有七個章節，前五章均為各自獨立的案
例分析，後兩章為策略與樣式的整理列表。印刷很不錯，字體大小恰當且清晰，也有很豐
富有趣的插圖。不過內容可是相當艱深，沒有充分的抽象與想像力，是不容易理解的。獨
立閱讀本書可說是非常吃力，我是建議能有幾位同好們一起研讀，甚至以角色扮演的方式
，來思考所抓出來的類別，以及所賦予其責任的合理性與正確性。
本書的類別表示法均是採用作者自創的語法 (Coad Notation)，它可說是自成一格，例如
多重性(multiplicity)就剛好是與 UML 類別圖的表示法完全相反，所以一定要先閱讀附
錄的語法說明。再則從每個案例研討的過程當中，作者總是會列出他在某個分析階段時所
使用的策略或樣式，並將之編號整理在後兩個章節。這個相當的有參考價值，但不要直接
就是翻閱這些策略與樣式列表，那可是相當的枯燥乏味，最好就是配合著這些案例的過程
說明，久而久之，你閱讀起來才會習慣也比較能有感覺。
多重性(multiplicity)就剛好是與 UML 類別圖的表示法完全相反，所以一定要先閱讀附
錄的語法說明。再則從每個案例研討的過程當中，作者總是會列出他在某個分析階段時所
使用的策略或樣式，並將之編號整理在後兩個章節。這個相當的有參考價值，但不要直接
就是翻閱這些策略與樣式列表，那可是相當的枯燥乏味，最好就是配合著這些案例的過程
說明，久而久之，你閱讀起來才會習慣也比較能有感覺。
誰需要閱讀本書呢？ 我是覺得想立志當個真正的“軟體人”是必備的。要知道，軟體設
計大概可以分為三個層次；1.把系統“做”出來；2.讓系統效能好一些；3.讓系統更有彈
性，來順應變化。 第一個只要有不錯的實作能力，以及功能需求的分析能力即可；第二
個則需要有對平台的專業知識能力，能充分發揮系統的效能特性；第三個那可真的需要對
軟體的“道”有著長期持續的信仰與熱情方可。我是以為，若能進入到第三個層次，修練
該層次所傳授的法，那絕對會是一種無以言語的喜樂。不過，現今國內軟體產業重視速食
文化，大約只要求在前兩個層次，第三個層次，曠時廢日，不太容易短時間內有著顯著的
實質回饋，因而堅持者甚少，殊為可惜。
計大概可以分為三個層次；1.把系統“做”出來；2.讓系統效能好一些；3.讓系統更有彈
性，來順應變化。 第一個只要有不錯的實作能力，以及功能需求的分析能力即可；第二
個則需要有對平台的專業知識能力，能充分發揮系統的效能特性；第三個那可真的需要對
軟體的“道”有著長期持續的信仰與熱情方可。我是以為，若能進入到第三個層次，修練
該層次所傳授的法，那絕對會是一種無以言語的喜樂。不過，現今國內軟體產業重視速食
文化，大約只要求在前兩個層次，第三個層次，曠時廢日，不太容易短時間內有著顯著的
實質回饋，因而堅持者甚少，殊為可惜。
※ 引述《VisualStudio (2017)》之銘言：
: 各位前輩好，
: 小弟最近在工作上接觸到
: 「Domain-driven design 領域驅動設計」的概念方法，
: 有在網路上看了些介紹文章，
: 也有找到滿多相關書籍，很多是英文書，
: 想請問大家有沒有哪一本書比較推薦呢?
: 或平常有使用到領域驅動設計嗎?
: https://imgur.com/CNvs61A
![[圖]](https://i.imgur.com/CNvs61Ah.png)
--
FB社團：軟體設計鮮思維
https://www.facebook.com/groups/softthinking/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.34.122.227
※ 文章代碼(AID): #1R7thSVm (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1528789724.A.7F0.html
--
※ 看板: dinos 文章推薦值: 0 目前人氣: 0 累積人氣: 184
回列表(←)
分享