淺談領域模型

|0x00 領域模型是什麼

領域模型是什麼？一句話：“經濟基礎決定上層建築”中的“經濟基礎”，是幫助理解複雜業務領域問題的基石。

有人說：“領域模型是一個商業概念，同行業的企業，一定有內在的共性，是幫助系統分析人員認識現實業務的工具。”領域，即邊界的意思，有了清晰的邊界，協作才有了利益的基礎；模型，即知識體系，深入理解了業務知識，開發才不會走過多的彎路。一般意義上的領域模型是面向軟體工程領域的，而現實意義的領域模型則包含了商業模式等廣義上的概念。

很多人一上來理解領域驅動設計（DDD），基本都是一頭霧水，因為模型設計的初衷並不是圍繞效能、架構、分層等軟體概念展開的，而是從邊界、內聚等抽象概念開始講起。理解領域模型，並不是通過技術的思維來學習，而是通過不斷地實踐過程來訓練自我的思維意識，進而徹底形成結構化與物件導向的思維方法論。

領域模型並不能直接帶來收益，只是輔助我們去理解正在做的事情。

引用百度的說法，“領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型、領域物件模型、分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。”總結一下，就是“準確描述問題，清晰描述方案”。

如果說軟體開發的本質，是從“問題空間”到“解決方案空間”的轉化，那麼“領域模型”，就是“解決方案空間”的架構，通過抽象的模型，為系統帶來統一的認知。

|0x01 領取模型怎麼設計

設計領域模型之前，首先要確定“問題空間”，即對需求進行分析和拆解。值得注意的是，領域模型通常是針對比較大的系統設計而言，如果是日常功能迭代中的小需求，那麼只需要根據已經設計好的模型原則，來做對應的開發即可。

需求分析階段要做的就是確定系統要實現的核心功能是什麼，用UML來表達設計意圖是非常好的工具。UML通過動靜結合的圖示，便可以比較清楚的闡述系統的核心職責與過程。

• 類圖：靜態，展示了模型中存在的類、類的內部結構以及它們與其他類的關係等；
• 狀態機：動態，對一個單獨物件的行為建模，指明物件在它的整個生命週期裡，響應不同事件時，執行相關事件的順序；
• 時序圖：動態，描述物件之間傳送訊息的時間順序顯示多個物件之間的動態協作。

接下來，就是業務建模階段了。在大多數講領域驅動的書籍裡，都會將領域劃分為：領域，子域和限界上下文。領域是一個模型所包含的全部事情；子域是指模型的某個細分部分，根據重要性可以劃分為核心、支撐和通用；限界上下文是一個業務邊界，邊界內的術語都有其特定的涵義，例如銀行系統和電商系統中顧客就不是同一個意思。這種劃分方式通常是非常靈活的，跟設計者的個人經驗有比較大的關係。

將系統拆分完成後，就需要確定子域/上下文之間的關係，以及相互之間的資訊如何進行流轉，例如：

• 模型概念
• 模型屬性和屬性值
• 模型之間的關係

最後，就是通過某些具體的方法論，分析具體的模型設計了。設計的方法論也有很多種，例如在用例分析方法中，就是儘可能的收集用例素材，通過例圖，以圖形化的方式將系統描述成用例、參與者（使用者）及其之間的關係；在DODAF中，是採用標準方法，表述“EA的資料和關係型別”的指引，解決複雜系統結構化問題的指引。在四色建模法中，用藍色表示命令，用紅色表示實體，用綠色表示領域事件，用黃色表示補充資訊，相關的實體便可以整理到同一個領域中。建模方式有很多種，不論是已有的方法論，或者是通過日常的業務經驗積累來設計，只要能將模型描述清楚，都是可用的。

做個總結，就是拋開技術視角，用純業務的視角來建立模型。但確定的一點是，領域模型的優先順序要高於軟體解決方案，先有領域建模的整體框架，然後才是將模型對映到軟體架構之中。

|0x02 領域模型的價值

建模是一個團隊性的複雜工作，經過長時間的摸索，有幾個特點還是可以總結出來：

• 建模的時候，不要立刻開始設計具體的模型，而是先對業務進行分析和拆解；很多時候，業務人員也不一定非常熟悉業務，前期調研的過程是必不可少的。
• 為了避免產生歧義，在建模的過程中最好使用統一的術語與工具，例如UML。
• 學會適應變化，模型本身是會發生變化的，變化的頻率取決於業務發展的速度，當下的形態都是某種意義上的中間態。

一個好的軟體系統，需要同時在滿足業務需求和系統底層架構之前做權衡，產品運營往往不具備技術背景，因此在“做不做”與“怎樣做”之間，往往會爆發激烈的衝突。更多的時候，是對同樣的概念，雙方都有不同的理解，這種GAP不一定是“大到天邊”的那種差異，而是針對某些具體的細節發生了誤解，但這種細節往往非常致命。這時候，通過模型來反應實際的業務情況，相當於說明書的作用，來與需求方溝通，就會有效的多。

因而，從全域性的角度看，領域模型會帶來如下的價值：

• 統一語言：溝通更加順暢，分歧易於解決；
• 知識沉澱：通過對業務領域的熟悉過程，能夠以模型的方式沉澱下來，對於自己提升與團隊傳承均有幫助；
• 保持清晰：在需求溝通時，能夠快速明確哪些需求是合理的，哪些是違反業務規則的，可以讓業務跑的更快的同時，保持系統結構的清晰。

|0xFF 數字化轉型

看完前面的內容，大多數人會有一種疑問，即領域模型適用在哪裡？大多數的網際網路場景下，用了領域模型，反而會讓業務更復雜。其實自Eric Evans在2003年出版《領域驅動設計：軟體核心複雜性應對之道》之後，領域模型的概念才深入人心，那會網際網路發展的並不充分。而隨著近幾年越來越多的企業意識到數字化的重要性，如何用資料去驅動特定行業的發展，比如製造業，慢慢的成為了一種潮流。在這種潮流裡，革新傳統行業的大概率不是從傳統行業走出來的人，而是依賴於掌握了數字化技術的人，技術人怎樣快速去了解和深入一個陌生的行業呢？領域模型自然就派上了用場。

例如在資訊時代常見的生產力工具ERP和MES，能夠解決資訊化的很多問題，但是對於生產流轉的過程掌握，就不那麼適用了，尤其是5G之後很多裝置也具備了數字化的特徵。用以“資料流”為主要特點的新管理系統，去適應和替代原有的生產系統，就顯得很有必要。但過去的“資料流”依賴於Hadoop體系及維度模型，這套組織方式套用到過去的管理系統中，會產生很多的不適應性，因而通過領域模型的方式，去抹平技術上的種種差異，為傳統VS網際網路行業的人達成共識，共同推動系統改造，就創造了基礎。