Re: [閒聊] Domain Knowledge
關於「Domain Knowledge」，這裡先釐清下軟體開發所謂的領域基本觀念。
問題領域 (problem domain)：
待解決問題所在的領域。例如「線上商品購物系統」、「戶政管理系統」，前者的問題領
域為「商品購物」；後者的問題領域為「戶政事務」。
解題領域 (solution domain)：
為了實現 (realize)問題領域所提出的解決方案與相關技術。例如商品訂購系統採用
Java/Spring/Linux 實現、戶政系統採用 C#.NET & .NET Framework/Windows Server
等相關技術來實現。
這兩個領域均各需有專家並能相互合作。
問題領域的專家稱為「Domain Expert」，他熟悉該業務領域的關鍵知識與業務流程
(business process)；而一般操作人員 (operator)則較熟悉某局部功能的操作細節 (畫
面表單的操作與欄位細節等)。
解題領域的專家，回到軟體開發這個圈子，大致有兩個角色比較重要的 (單指軟體技術而
言，不涉及專案管理)：一為軟體架構師 (architect)、另一為實作技術的Leader，例如
CTO。架構師重視的是如何調合需求分析、結構設計與寫碼實作；而CTO當然就是對如
Java/C#.NET 的實作具化能力。因為實作技術的多樣化及快速的變遷，所以與其說高深
的技術人員懂多少技術、倒不如說他是否具備能快速學會相關實作技術的 Skill，這反而
比懂多少還要更重要。
這兩個領域的專家所需具備的知識與技能均不相同，但卻要能相互合作，這是軟體系統是
否能搭配領域知識進而創造出所謂的「business value」關鍵之所在。要說有同時能具備
兩者領域的專家，只能說以個人在這個業界10多年來是沒有看過 (或許真有這種天賦異稟
的奇才)，雖然期間有碰過許多專案經理號稱有，但是﹒﹒﹒
從程式碼反映出來的並非稱為「domain knowledge」，程式碼只是為了實現所需完成的功
能，而且往往看到的都是片段局部的功能而已。
至於軟體專家如架構師，倒是可以從程式碼看出它的結構性，諸如靜態的類別結構，以及
動態的物件呼叫關係，並進而審視與議定該結構的好壞與合理性與否。
附帶說明下，一般業界幾乎是要求 SA/SD 具備該問題領域的知識，其實這蠻有問題的，
因為反而 SA/SD 並沒有具備了軟體相關包括需求/結構設計等應具備的技能，且得到所謂
問題領域的知識都往往僅限於局部。與其說要求 SA/SD 具備問題領域知識，倒不如說了
解如何與問題領域專家溝通的技能反而才是重點。
SA/SD 應具備的是「domain natural」的分析/萃取的抽象能力，而這些相關技能/技術，
則是偏向為「純」軟體領域這個範疇。
※ 引述《AmosYang (泛用人型編碼器)》之銘言：
: ※ 引述《csfgsj (Lazy bone)》之銘言：
: : 曾經有一個老竽仔跟我說
: : 如果你在看程式碼的時候，能看到程式語言以外的思維
: : 那就是它啦！Domain knowledge
: : 它偶爾會冒出來
: : 在大部分都是程式語言的視野中佔據一小角
: : 隨著時間的漂移
: : 你會發現越來越多程式語言以外的思維從程式碼中冒出來
: : 佔據越來越多的視野
: : 相對的，程式語言所佔的視野會越來越小
: : 直到有一天
: : 當所有的視野通通與程式語言無關時
: : 那你就出師了
: 同意；其實，把 domain knowledge 想成「創造 business value 的
: 工具」的話，就很好理解
: 以「這個按鈕按下去後，列出所有資料」這功能為例
: 首先自然是刻 UI ，把客戶端接上後端，後端大概再寫個去撈資料的
: 東西，最後把資料吐出來
: 接下來就是最潮的 domain knowledge 惹
: * 這軟體是賣給誰用? 若是要賣給美國公家機關，刻 UI 時就要懂得
: 要設計成色盲也能用，若有用顏色來作 visualization 的話，就
: 要設計成有灰階版本的；要設計成身體不方便的人也能用，例如，
: 每個 UI 元件要支援 speech 功能, 要支援 high contrast, 要與
: OS 內建的各種 sticky key / tab key 等等功能相容 ...
: * 這軟體是處理什麼資料? 這些資料的特性為何? 例如: 安全性? 或
: 著，是否需要遵守 document retention 的各種法律? 資料量有多
: 大? 是否要 server-side paging? 資料的「本質」為何? 是否該
: 設計分析功能? 要設計怎麼樣的分析功能? 統計分析? visualization?
: data mining?
: * 軟體開發本身的 domain knowledge, 例如 agile, CI, devops;
: ， dev-qa-pm 是 heaven 的三位一體還是 hell 互婊三巨頭?
: PM 是否有給予 dev 足夠的 context? 還是把 dev 關在黑箱裡
: 直接要他們去實作 PM 想像中的 solution?
: dev 與 qa 是否知道這產品是為什麼而做? 做了要賣給誰?
: etc.
: 其他的，什麼 i18n, 會不會踩到別人的專利? 踩到了是要戰還是要
: 和；這個專案的時程為什麼這樣排? 這產品的競爭對手是誰? 價格如
: 何定? 如何黏住你的用戶? 有的沒的
: 易言之，「到底解決了什麼問題? 創造了何種 business value?」
: ============================================================
: 基本上，認識 *domain knowledge* 最簡單的方式，應該是
: 1. 取得該產業裡一般公認的最基本入門知識與技能，例如，以軟體
: 業來說，「取得 Computer Science 學士學位」是個最常見的方
: 法
: 2. 進入業界，從「在這個業界，若要讓公司活下去，成長茁壯，需
: 要怎麼樣的知識與技能? 」的角度去看事物以及每天發生的各種
: 大大小小的事件
: 3. ???
: 4. Profit!!!
: 總結:
: 在背景知識與實務經驗間取得平衡，競爭之後活下來；你所經歷的
: 一切，就可說是 *domain knowledge*
--
FB 社團：軟體設計鮮思維
http://ppt.cc/~4VN
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.32.107.221
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1425220622.A.4D6.html
→
03/04 12:29, , 1F
03/04 12:29, 1F
討論串 (同標題文章)