開發人員必須鉆研領域以獲取業務知識。他們必須磨礪其建模技巧，并精通領域設計。
Eric《Domain-Driven Design》
所謂的領域建模，是一種通過日常不斷實踐，來強化開發人員思維，逼迫開發人員進入深度思考的過程，并通過在這個過程中的不斷錘煉，可以使得開發人員形成結構化思考方式的方法論。
領域模型
概念模型
現實世界中對象可視化表達
問題領域? > 業務領域概念 > 建立業務領域概念之間的關系
“物質基礎決定上層建筑”?
馬克思
從架構上來說，領域模型是處于應用架構的最底層，Domain層涵蓋了模型治理、流程抽象、流程治理等方面的知識。我們可以很清楚地看到，如果領域模型沒有把控好，那么就相當于大樓地基沒有打好，帶來的后續建筑或是維護成本之高，是難以想象的。
Explore the problem space before thinking about the solution
https://mashhoodalam.com/2015/07/03/what-is-design-thinking-and-why-is-it-better/
先探索問題空間，然后再考慮解決方案。
首先使用發散思維, 探索有關利益相關者及其背景的所有不同觀點，總結歸納出對利益相關者的共同理解，并使用聚合思維定義需要解決的問題。
?這有助于在考慮“如何”和“什么”之前回答倡議的“為什么”。
抽象領域模型的具體步驟:
1.收集用例描述集合
?一系列需求文字描述的用例集合
2.尋找概念
對用例描述進行語言分析，識別名詞
3.添加模型關聯
名詞之間存在語義聯系，則往往存在模型關聯，例如上面的發布，聯系了金牛和文章兩個名詞
4.屬性完善
形容詞完善，例如上面的領域建模相關，如果文章存在標簽屬性，那么它的值在我們這個用例里就是領域建模。
實際的工程中領域建模，會比這個復雜。例如還存在子域劃分、模型組合等手段。
學會了領域建模，有助于提升自己的抽象能力。如果在早期就有了抽象的思維，你會發現隨著時間推移，你所需要建立的“原則”越來越少，已有的原則會越來越完善。
架構概論
1. 什么是架構
架構就是對系統中的實體以及實體之間的關系所進行的抽象描述，是一系列的決策。
架構是結構和愿景。
系統架構是概念的體現，是對物/信息的功能與形式元素之間的對應情況所做的分配，是對元素之間的關系以及元素同周邊環境之間的關系所做的定義。
做好架構是個復雜的任務，也是個很大的話題，本篇就不做深入了。有了架構之后，就需要讓干系人理解、遵循相關決策。
系統架構圖是為了抽象的表示軟件系統的整體輪廓和各個組件之間的相互關系和約束邊界，以及軟件系統的物理部署和軟件系統的演進方向的整體視圖。
一圖勝千言。要讓干系人理解、遵循架構決策，就需要把架構信息傳遞出去。架構圖就是一個很好的載體。那么，畫架構圖是為了：
解決溝通障礙
達成共識
減少歧義
搜集了很多資料，分類有很多，有一種比較流行的是4+1視圖，分別為場景視圖、邏輯視圖、物理視圖、處理流程視圖和開發視圖。
畫架構圖遇到的常見問題
為什么適用方框而不是圓形，它有什么特殊的含義嗎？隨意使用方框或者其它形狀可能會引起混淆。
隨意使用線條或者箭頭可能會引起誤會。
3. 運行時與編譯時沖突？層級沖突？架構是一項復雜的工作，只使用單個圖表來表示架構很容易造成莫名其妙的語義混亂。
推薦的畫圖方法
C4 模型使用容器（應用程序、數據存儲、微服務等）、組件和代碼來描述一個軟件系統的靜態結構。這幾種圖比較容易畫，也給出了畫圖要點，但最關鍵的是，我們認為，它明確指出了每種圖可能的受眾以及意義。
下面的案例來自 C4 官網，然后加上了一些我們的理解，來看看如何更好的表達軟件架構
1. 語境圖(System Context Diagram)
這是一個想象的待建設的互聯網銀行系統，它使用外部的大型機銀行系統存取客戶賬戶、交易信息，通過外部電郵系統給客戶發郵件。可以看到，非常簡單、清晰，相信不需要解釋，都看的明白，里面包含了需要建設的系統本身，系統的客戶，和這個系統有交互的周邊系統。
這樣一個簡單的圖，可以告訴我們，要構建的系統是什么；它的用戶是誰，誰會用它，它要如何融入已有的IT環境。這個圖的受眾可以是開發團隊的內部人員、外部的技術或非技術人員。即：
構建的系統是什么
誰會用它
如何融入已有的IT環境
中間是自己的系統，周圍是用戶和其它與之相互作用的系統。這個圖的關鍵就是梳理清楚待建設系統的用戶和高層次的依賴，梳理清楚了畫下來只需要幾分鐘時間。
容器圖是把語境圖里待建設的系統做了一個展開。
上圖中，除了用戶和外圍系統，要建設的系統包括一個基于java\spring mvc的web應用提供系統的功能入口，基于xamarin架構的手機app提供手機端的功能入口，一個基于java的api應用提供服務，一個mysql數據庫用于存儲，各個應用之間的交互都在箭頭線上寫明了。
看這張圖的時候，不會去關注到圖中是直角方框還是圓角方框，不會關注是實線箭頭還是虛線箭頭，甚至箭頭的指向也沒有引起太多注意。
我們有許多的畫圖方式，都對框、線的含義做了定義，這就需要畫圖的人和看圖的人都清晰的理解這些定義，才能讀全圖里的信息，而現實是，這往往是非常高的一個要求，所以，很多圖只能看個大概的含義。
這個圖的受眾可以是團隊內部或外部的開發人員，也可以是運維人員。用途可以羅列為：
展現了軟件系統的整體形態
體現了高層次的技術決策
系統中的職責是如何分布的，容器間的是如何交互的
告訴開發者在哪里寫代碼
用一個框圖來表示，內部可能包括名稱、技術選擇、職責，以及這些框圖之間的交互，如果涉及外部系統，最好明確邊界。
組件圖是把某個容器進行展開，描述其內部的模塊。
這個圖主要是給內部開發人員看的，怎么去做代碼的組織和構建。其用途有：
描述了系統由哪些組件/服務組成
厘清了組件之間的關系和依賴
為軟件開發如何分解交付提供了框架
這個圖很顯然是給技術人員看的，比較常見，就不詳細介紹了。
案例分享
下面是內部的一個實時數據工具的架構圖。作為一個應該自描述的架構圖，這里不多做解釋了。如果有看不明白的，那肯定是還畫的不夠好。
畫好架構圖可能有許多方法論，本篇主要介紹了C4這種方法，C4的理論也是不斷進化的。但不論是哪種畫圖方法論，我們回到畫圖初衷，更好的交流，我們在畫的過程中不必被條條框框所限制。簡而言之，畫之前想好：畫圖給誰看，看什么，怎么樣不解釋就看懂。
