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