From: https://liudongdong1.github.io/
微服務架構，在集中式架構中，系統分析、設計和開發往往是獨立進行的，而且各個階段負責人可能不一樣，那么就涉及到交流信息丟失的問題， 另外項目從分析到開發經歷的流程很長，很容易最終開發設計與需求實現的不一樣，微服務主要就是解決第二階段的這些痛點，實現應用之間的解耦，解決單體應用擴展性的問題。
1. 概念
面對客戶的業務需求，由
領域專家與開發團隊展開充分的交流，經過需求分析與知識提煉，以獲得清晰的問題域。通過對問題域進行分析和建模，識別限界上下文，利用它划分相對獨立的領域，再通過上下文映射建立它們之間的關系，輔以分層架構與六邊形架構划分系統的邏輯邊界與物理邊界，界定領域與技術之間的界限。之后，進入戰術設計階段，深入到限界上下文內對領域進行建模，並以領域模型指導程序設計與編碼實現。若在實現過程中，發現領域模型存在重復、錯位或缺失時，再進而對已有模型進行重構，甚至重新划分限界上下文。兩個不同階段的設計目標是保持一致的，它們是一個連貫的過程，彼此之間又相互指導與規范，並最終保證一個有效的領域模型和一個富有表達力的實現同時演進。
2. 提煉問題閾
3. 專注核心問題
在
一個大的問題空間中會同時存在很多的小問題域，而這些小問題域往往只有少部分是核心領域，其他的可能都是通用域和支撐域。核心域是我們軟件的根本競爭力所在，因此也可以說是我們編寫軟件的原因。拿一個在線拍賣網站來說，可以見下圖所示划分了核心域、支撐域和通用域：
4. 驅動模型設計
模型驅動設計專注於實現以及對於初始模型可能需要修改的約束，領域驅動設計則專注於語言、協作和領域知識，他們是一個彼此互補的關系。而要實現協作，就需要使用通用語言，借助通用語言可以將分析模型和代碼模型綁定在一起，並最終實現團隊建模。實踐UL是一個持續的過程，多個迭代后會不斷對UL進行驗證和改進，以便實現更好的協作。由於時間和精力都有限，只有僅僅為核心域應用模型驅動設計和創建UL才能帶來最大的價值，而不需要將這些實踐應用到整個應用程序之中。
5. 領域模型實現模式
- 領域模型模式：適用於復雜問題域，領域中的概念被封裝為數據和行為的對象
- 事務腳本模式：組織所有的領域邏輯來滿足業務事務或用例
- 表模塊模式：代表着以對象形式建模的數據，數據驅動
- 活動記錄模式：類似表模塊，數據驅動，關注表中的行而非表本身
- 貧血模式：類似領域模型，不包含任何行為，純粹的一個對象狀態模型，需要一個單獨的服務類來實現行為
6. 使用有界上下文維護領域模型的完整性
從
展現層、領域邏輯層再到持久化層的完整代碼堆棧，正應對了我們的每一個微服務的應用程序，也具有較高的獨立性，擁有自己的數據庫和一套完成的垂直切片的架構模式。不應該局限在某一種或者兩種架構模式上，而是應該量身應用，沒有復雜性業務邏輯的微服務，那就應該KISS（Keep It Simple & Stupid），否則就可以考慮DDD。
7. 上下文映射
上下文映射用來
捕獲各個有界上下文之間的技術與組織關系，它最大的作用就是保持模型的完整性。在戰略設計階段，針對問題域，通過引入限界上下文和上下文映射可以對問題域進行合理的分解，識別出核心領域和子領域，並確定領域的邊界以及他們之間的關系，從而維持模型的完整性。限界上下文不僅局限於對領域模型的控制，而在於
分離關注點之后，使得整個上下文可以成為獨立部署的設計單元，這就是我們非常熟悉的“微服務”的概念；而上下文映射的諸多模式則對應了微服務之間的協作。
8. 應用程序架構
9. 團隊開始應用DDD通常會遇到的問題
10. 應用DDD的原則、實踐與模式
