《領域驅動設計-軟體核心複雜性應對之道》：全書圍繞著設計和開發實踐，結合若干真實的專案案例，向讀者闡述如何在真實的軟體開發中應用領域驅動設計。書中給出了領域驅動設計的系統化方法，並將人們普遍接受的一些最佳實踐綜合到一起，融入了作者的見解和經驗，展現了一些可擴充套件的設計最佳實踐、已驗證過的技術以及便於應對複雜領域的軟體專案開發的基本原則。適合各層次的物件導向軟體開發人員、系統分析員閱讀。隨著軟體系統越來越龐大，需求越來越模糊，**越來越混亂，測試越來越困難，技術演進基本不可能，而其中大型複雜的軟體專案更容易走向系統老化的過程，形成需求難、開發難、測試難、創新難，單體架構區域性業務膨脹可以拆成微服務，那麼微服務區域性業務膨脹又應該怎麼做？ddd之所以火，即能解決微服務解決不了的問題。ddd是為了解決快速變化、複雜系統的設計問題。《**精進之路從碼農到工匠》：共有13章內容，主要分為技藝部分、思想部分和實踐部分。技藝部分詳細介紹了程式設計技巧和方**，並配以詳盡的**案例，有助於讀者提高編寫**的能力，優化**質量。思想部分主要包括抽象能力、分治思想，以及程式設計師應該具備的素養等內容。實踐部分主要介紹了常見的應用架構模式，以及cola架構的設計原理。
ddd的革命性在於領域驅動設計是物件導向分析的方**，它可以利用物件導向的特性（封裝、多型）有效地化解複雜性，而傳統j2ee或spring+hibernate等事務性程式設計模型只關心資料。這些資料物件除了簡單的setter/getter方法外，不包含任何業務邏輯，業務邏輯都是以過程式的**寫在service中。這種方式極易上手，但隨著業務的發展，系統也很容易變得混亂複雜。
學習、理解及應用領域驅動設計建議先有以下幾個基礎條件：
如何解決系統老化問題使得重新崛起的ddd領域驅動設計成了業界最大的希望乃至目前階段最理想的方式，積極踐行ddd，搭建的每乙個應用，實現的每乙個功能，寫的每一行**，都是在精修架構思維的內功。過去系統分析和系統設計都是分離的，ddd則打破了這種隔閡，提出了領域模型概念，統一了分析和設計程式設計，使得軟體能夠更靈活快速跟隨需求變化。先來理解幾個概念：
傳統架構的設計邏輯從資料庫出發，先進行資料庫設計、建表、字段不合理再調整，表和物件進行管線。而ddd是把資料庫當成與其他元件相等的一環，可以解決現有系統因為資料庫，而導致系統耦合問題。而適應快節奏的需求變更頻繁的敏捷開發的出現，更是對傳統架構的設計產生較大影響，架構師作為架構設計文件和圖形的載體。
ddd中的設計主要指領域模型的設計。為什麼是領域模型的設計而不是架構設計或其他的什麼設計呢？因為ddd是一種基於模型驅動開發的軟體開發思想，強調領域模型是整個系統的核心，領域模型也是整個系統的核心價值所在。每乙個領域，都有乙個對應的領域模型，領域模型能夠很好的幫我們解決複雜的業務問題。領域模型設計只是整個軟體設計中的很小一部分。除了領域模型設計之外，要落地乙個系統，我們還有非常多的其他設計要做，比如容量規劃、架構設計、資料庫設計、快取設計、框架選型、發布方案、資料遷移、同步方案、分庫分表方案、回滾方案、高併發解決方案、一致性選型、效能壓測方案、監控報**案等。
一般系統設計分為概念設計、邏輯設計、物理設計三個階段。
邏輯設計：
物理設計：
基本定義
乙個領域本質上可以理解為乙個問題域，只要是同乙個領域，那問題域就相同。任何乙個系統都會屬於某個特定的領域，比如論壇是乙個領域，只要你想做乙個論壇，那這個論壇的核心業務是確定的，比如都有使用者發帖、回帖等核心基本功能；傳統電商領域的問題無非就是訂單、商品、支付、物流、庫存之類，而社交電商除了傳統電商的屬性外，也會附加社交、通訊相關的功能。所以同乙個領域的系統都具有相同的核心業務，因為他們要解決的問題的本質是類似的。
只要我們確定了系統所屬的領域，那這個系統的核心業務，即要解決的關鍵問題、問題的範圍邊界就基本確定了。通常我們說，要成為乙個領域的專家，必須要在這個領域深入研究很多年才行。因為只有你研究了很多年，你才會遇到非常多的該領域的問題，同時你解決這個領域中的問題的經驗也非常豐富。很多時候，領域專家比技術專家更加吃香，比如金融領域的專家。
領域劃分以事件風暴的形式（event storming），列出所有的使用者故事（use story），使用者故事可通過6w模型來構建，即描寫場景的 who、what、why、where、when 與 how 六個要素。然後圈選功能相近的部分，就形成了領域，領域又根據職能不同劃分為：核心域、支撐域、通用域，
驅動領域驅動領域模型設計，領域模型驅動**實現。這個就和我們傳統的資料庫驅動開發的思路形成對比了。ddd中，我們總是以領域為邊界，分析領域中的核心問題（核心關注點），然後設計對應的領域模型，再通過領域模型驅動**實現。而像資料庫設計、持久化技術等這些都不是ddd的核心，而是外圍的東西。
領域驅動設計（ddd）的最大價值：當我們要開發乙個系統時，應該盡量先把領域模型想清楚，然後再開始動手編碼，這樣的系統後期才會很好維護。但是，很多專案（尤其是網際網路專案，為了趕工）都是一開始模型沒想清楚，一上來就開始建表寫**，**寫的非常冗餘，完全是過程是的思考方式，最後導致系統非常難以維護。而且更糟糕的是，出來混總是要還的，前期的領域模型設計的不好，不夠抽象，如果你的系統會長期需要維護和適應業務變化，那後面你一定會遇到各種問題維護上的困難，比如資料結構設計不合理，**到處冗餘，改bug到處引入新的bug，新人對這種**上手困難，等。而那時如果你再想重構模型，那要付出的代價會比一開始重新開發還要大，因為你還要考慮相容歷史的資料，資料遷移，如何平滑發布等各種頭疼的問題。所以，就導致我們最後天天加班。從面向過程式的想到**寫到**的思想轉變為基於系統化的模型驅動的思維很難，這或許是ddd很難在中國或國外流行起來的原因吧。
設計ddd中的設計主要指領域模型的設計，ddd是一種基於模型驅動開發的軟體開發思想，強調領域模型是整個系統的核心，領域模型也是整個系統的核心價值所在。每乙個領域，都有乙個對應的領域模型，領域模型能夠很好的幫我們解決複雜的業務問題，從領域和**實現的角度來理解，領域模型繫結了領域和**實現，確保了最終的**實現就一定是解決了領域中的核心問題的。
子域可以理解為更加細分的領域，甚至可以把子域進行更新劃分，分成更多的子域。比如把電商平台看成是乙個領域，那麼訂單、倉儲、物流都可以是子域，而倉儲可以劃分為本地倉儲、三方倉儲、異地倉儲等子域。子域可以劃分為三種型別
能夠正確的、簡單的、清晰的表達業務，並讓專案的參與人員都能夠達成共識的語言。統一語言是提煉領域知識的輸出結果，也是進行後續需求迭代及重構的基礎，統一語言的建立有以下幾個要點：
語義問題，蘋果不大好吃這句話可以理解為蘋果，不大好吃，也可以理解為蘋果不大，好吃。限界上下文用來封裝封裝通用語言和領域物件，提供上線文環境，保證在領域內的一些術語、業務相關物件等有乙個確切的含義、沒有二義性，這個邊界定義模型的使用範圍。那上面例子來說，蘋果不大好吃，下次再也不買了。
限界上下文包含兩部分：上下文（context）是業務目標，限界（bounded）則是保護和隔離上下文的邊界。限界上下文沒有統一的劃分標準，需根據自己的業務場景來甄別如何劃分。乙個上下文中包含了相同的領域知識，角色在上下文中完成動作目標；邊界體現在以下幾方面：
戰略設計是一種用高層次的視野來審視軟體系統的方式，戰略設計也可以出現建模的方式問題、頻繁進行戰略改動問題。uml建模，適合小範圍。關聯關係、引用關係，解決複雜問題如四色建模法、限界紙筆法、事件風暴。
領域模型是對領域內的概念類或現實世界中物件的視覺化表示。包括業務物件模型、業務物件之間的引用關係。
領域建模方法
領域模型的核心作用：
業務物件模型就是業務邏輯流轉的過程中需要的所有角色，甚至還包括你的業務邏輯流轉本身。業務模型在ddd大概實現有四種方式
缺點
缺點
充血模型
缺點
缺點失血模型和漲血模型是現在不太推薦的使用的模型，貧血模型是用的最多的，而充血模型對於程式設計師的要求非常高。貧血模型的物件會被各種service呼叫，分布在不同業務中，對於業務理解難度加大。而充血模型每個實體操作自己實體的變化，跨實體的變化通過領域服務實現，領域服務呼叫實體方法完成狀態改變。
**本人部落格** **it小神www.itxiaoshen.com
架構師修煉之微服務部署 Docker簡介
docker 是乙個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到乙個可移植的容器中,然後發布到任何流行的linux機器或windows 機器上,也可以實現虛擬化,容器是完全使用沙箱機制,相互之間不會有任何介面。docker動手實驗平台 play with docker。docker 最...
微服務架構師的職責 《微服務設計讀書筆記》
如何定義架構師 架構師從英文單詞architect翻譯而來，在英文中，architect 原來的意思是 建築師 作者吐槽英文中架構師與傳統的建築師單詞相同，但實際的工作性質並不相同，以致於在英文的語境中會造成理解上的差異。傳統的建築師在設計建築時要求極端地精確，在正式施工之前會進行完整的論證 設計 ...
架構師之路（一）Nginx系列之負載均衡
1 反向 負載均衡服務概述 反向 外網主機 網際網路 中介 內網主機 正向 內網主機 網際網路 中介 外網主機 翻牆 反向 nginx，類似中介，中介幫你處理。負載均衡 lvs，資料 幫你 請求。2 反向 負載均衡配置過程 在負載均衡伺服器上進行測試 root lb01 curl h host ww...