領域專家X

Feb. 11 17:33~19:11

▲立志成為喵星人的領域專家

前言

無論是行為驅動開發（Behavior-Driven Development；BDD）、實例化規格（Specification By Example；SBE）或是領域驅動設計（Domain-Driven Design；DDD），共同存在一個非常重要的假設：「正確的需求可以藉由領域專家與開發團隊密切的迭代溝通所產生」。

在這個假設之下，領域專家彷彿「神一般的存在」，他的腦袋中似乎對所有問題都有答案，對於團隊的提問，他不會說：「都可以，由團隊決定」。

可能是領域專家知道的太多，他無法將所有事情主動告訴開發團隊，需要藉由團隊成員與他的互動，將完整的需求慢慢誘導出來。

這其實並不是什麼新觀念，傳統的軟體開發方法也都持相同看法，只不過BDD/SBE與DDD，特別是BDD/SBE這一系列的方法，特別強調此觀點。

***

落實BDD/SBE的困難

讀過BDD/SBE書籍的鄉民一定會發現，許多書本都會以一個例子來示範如何學習這些方法，例如停車費計算、搭乘巴士或捷運的車資計算、包裹運費計算。相對於一般的商業軟體，這些例子除了功能較少以外（系統較小），還有一個共同特色，就是有著非常明確的商業邏輯。

因為有著非常明確的商業邏輯，領域專家的角色就可以被簡化，也容易透過領域專家與開發人員之間的對話來釐清「規格」，進一步採取「舉例子」的方式來描述這些規格。作為學習目的，這樣的設計非常合理，並無不妥。

落實BDD/SBE的困難之一在於一個完整的系統除了「具備明確商業邏輯」的部分以外，也有許多功能的商業邏輯不是哪麼明確。又或者是這些邏輯不屬於核心商業邏輯（core business logic）， 而是應用程式邏輯　（application logic）。換句話說，領域專家也許對於核心商業邏輯比較清楚，但不一定對於應用程式邏輯有特別的意見。這時候通常需要由開發團隊來主導，再與領域專家確認。這個部分的系統實作，在BDD/SBE的書籍討論的比較少，因為這原本就不是這系列方法所著重的焦點。

舉個例子，以看板系統（Kanban System）為例，它本身有一些相對明確的核心商業邏輯，例如看板核心三原則：

• 視覺化
• 限制WIP（work in progress/process）
• 管理流

根據這三個原則可以舉出好幾的實例，這些都是領域專家比較熟悉的核心商業邏輯：

• 工作流視覺化實例，包含垂直工作流、水平工作流（swim lane）。
• 卡片（Card）視覺化：包含標準卡片、固定交期卡片、加急卡片、Bug修正卡片、技術工作卡片。
• 工作流加上WIP限制之後，卡片數量符合與違反WIP限制的例子。
• 阻礙（Blocker）的表達方式。
• Lead Time、Cycle Time的定義與量測方法。

真正實作看板系統的時候，有一些不屬於核心商業邏輯的應用程式邏輯會跑出來，例如：

• 一個使用者可以擁有多少個看板？
• 不同的使用者是否可以共用看板？
• 使用者要如何設計自己的看板？從頭開始設計，還是可以套用現成的模板（Template）？
• 一個看板只能表達一種工作流程，還是可以同時表達多個工作流程，以便於讓多個團隊共用看板？
• 已完成的卡片（當累積很多之後）要如何「收納」才不會阻礙使用者使用看板？
• 如何表達看板的開始與結束，以便於計算lead time？

以上總總問題，雖然也屬於開發看板系統需要釐清的邏輯，但並不屬於核心商業邏輯，因為不同的看板系統，可以有不同的決定。例如，路人甲所開發的Simple Kanban系統決定一個看板只能有一個工作流程，而路人乙所開發的myKanban系統則是支援一個看板可以有多個工作流程。

***

落實BDD/SBE的困難

相較於BDD/SBE，DDD因為要探討領域模型（domain model）、通用語言（ubiquitous language）、bounded context、context map以及aggregate、entity、value object、repository、service、factory等DDD設計模式，因此需要一個相對比較完整的系統開發作為例子，例如《Implementing Domain-Driven Design》就以開發敏捷專案管理系統當作例子。

落實DDD的困難之一在於如何找到一個「合適且完整的系統當作例子？」例子的問題領域很重要，因為學習者通常是軟體工程師，如果問題領域過於專業，例如健保系統、保險理賠系統、進銷存系統，軟體工程師很難在學習過程中弄清楚這些系統的核心商業邏輯與應用程式邏輯。如果例子太小，又失去套用DDD的意義。

為了解決缺少領域專家的問題，《Implementing Domain-Driven Design》作者選用了敏捷專案管理系統作為例子。一方面這個系統的大小適中，而問題領域又是開發人員比較容易理解的敏捷方法，因此開發人員可以自己腦補，同時扮演領域專家的角色。

***

真實世界的困難

剛剛從學習的角度來討論在學習BDD/SBE與DDD的時候，缺少真正領域專家所造成的問題。在真實世界中，這個問題是否就消失了？

雖然開發團隊應該會有專案經理、系統分析師、產品經理或Product Owner等角色來協助釐清系統需求，但實際上這些人很可能都不是真正的領域專家。就算團隊有領域專家的協助，但如前面所提到的，領域專家可以協助釐清核心商業邏輯，但對於應用程式邏輯的幫助相對較小。

此外，敏捷開發採用迭代與增量的方式，在開發過程需要持續與領域專家討論於釐清問題，但並不是所有領域專家都願意這樣子跟開發團隊配合。有些領域專家甚至認為：「這是開發團隊的工作，我為什麼要花自己的時間幫他們做事？」

所以，開發團隊不能無腦地一味將釐清商業邏輯的責任推給領域專家，而領域專家也應該多聽聽開發團隊的意見，不要把團隊提出的問題當成對自己專業知識的質疑，這是一種釐清問題的溝通過程。

***

友藏內心獨白：沒有的東西要去哪裡生？！