領域邏輯與應用邏輯

Dec. 10 13:50~14:49

名詞解釋

在物件導向分析與設計（Object-Oriented Analysis and Design；OOAD）、領域驅動設計（Domain-Driven Design）或是簡潔架構（Clean Architecture）中，經常會看到領域邏輯（Domain Logic）與應用邏輯（Application Logic）這兩個名詞。在Clean Architecture中，前者稱為關鍵業務規則（Critical Business Rule），後者稱為特定應用業務規則（Application-Specific Business Rule）。

一般針對這兩個名詞的解釋：

• 領域邏輯：特定業務領域（business domain）都適用的邏輯。
• 應用邏輯：在某個業務領域中，特定應用程式的邏輯。

一般情況下，除非很大型的系統，否則開發人員遇到的情況很可能只有開發一個業務領域中的一個應用程式。也就是說，不太容易區分這兩者，特別是對初學者而言。

***

例子

最近跟北科大資工系ezKanban團隊討論看板系統的領域模型（domain model）。原本的需求只需支援圖1中的看板系統。

▲圖1：看板系統範例

為了支援圖1的看板系統，ezKanban的domain model如圖2所示。

▲圖2：ezKanban的Domain Model

圖2暗示了一個領域邏輯：一個Stage（圖1中的待辦事項、分析、實作等）有一個預設的MiniStage（圖1中待辦事項底下的想法與Top 5），一個MiniStage有一個預設的SwiLane（用來放置工作卡片的物件）。

***

過了一陣子，Teddy覺得一個看板系統應該有一個預設的Stage用來存放剛剛新增的Work Item（工作卡片），還有另一個預設的Stage用來存放已完成的Work Item。如圖3所示。

▲圖3：新的看板系統需求，一個看板有兩個預設Stage：Backlog與封存（Archive）

如此一來，增加了一個新的邏輯：一個Board物件至少有兩個Stage，如圖4所示。

▲圖4：Board與Stage的關係

圖4中的關係，應該要算是領域邏輯還是應用程式邏輯？

很顯然地這應該是一個應用程式邏輯，因為ezKanban這個應用程式的要求，才讓Board與Stage產生這樣的關係限制。如果是其他人使用相同的domain model來開發看板系統，則不一定會對Board與Stage的關係規範這種限制。

所以要實作圖4的邏輯，應該是放在DDD所說的應用程式層（Application Layer），或是Clean Architecture裡面的使用案例層（Use Case Layer）。

至於圖2中Stage與MiniStage以及SwimLange的關係，屬於domain model的核心邏輯，所以在DDD裡面的Domain Layer（又稱為Model Layer）或是Clean Architecture的Entity Layer實作。

***

友藏內心獨白：分層負責才會乾淨。