概念
領域：邊界內要解決的業務問題域
子領域：在領域範圍內對應一個更小的問題域或更小的業務範圍
拆分過程
確認研究對象，即研究領域。
將對象進行細分，拆分爲子領域。
每個子領域再拆分，行成更小子領域。
核心域
決定產品和公司核心競爭力的子域是核心域，它是業務成功的主要因素和公司的核心競爭力。
註冊、登陸、充值、體現、下單、商品信息推送。
通用域
同時被多個子域使用的通用功能子域是通用域。
授權、認證等
支撐域：不屬於通用功能，但是不包含決定產品和公司核心競爭力的功能。
訂單拆分。
限界上下文
確定領域邊界。
通用語言
在事件風暴過程中，通過團隊交流達成共識的，能夠簡單、清晰、準確描述業務涵義和規則的語言就是通用語言。
通用語言包含屬於和用例場景，並且能夠直接反應在代碼中。通用語言中的名詞可以給領域對象命名、如商品、訂單等，對應實體對象；而動詞則表示是一個動作或實際，如商品已下單、訂單已付款等，對領域事件或或者命令。
實體
1.標識符->歷經狀態變更後標識符不產生變化，擁有延續性和標識，甚至超出軟件生命週期。
2.多個屬性、操作或行爲的載體。在事件風暴中，我們可以根據命令、操作或者事件，找出這些行爲的業務實體對象，進而按照一定的業務規則將依存度高和業務關聯緊密的多個實體對象和值對象進行聚類，行程聚合。
3.有ID標識，通過ID判斷相等性，ID在聚合內唯一。狀態可變，依附於聚合根，其生命週期由聚合根管理。實體一般會持久化，但是與數據庫持久化對象不一定是一對一。
業務形態：實體和值對象是組成領域模型的基礎單元。
代碼形態：充血模型，跨多個實體的領域邏輯在領域服務中實現。
ps：充血模型：大多業務邏輯和持久化放在Domain Object裏，Business Logic只是簡單封裝部分業餘邏輯以及控制事務、權限等，層次Client ->(Business Facade)->BUsiness Logic -> Domain Object ->Data Access
優點面向對象，Business Logic符合單一職責，不像貧血模型包含所有的業務邏輯太過沉重。
缺點，如何劃分業務邏輯，哪些邏輯在Domain Object，Domain Logic包含了持久化，對於開發者來說十分混亂，其次，Business Logic要控制事務，並且爲上一層提供一個統一的服務調用入口點，必須把Domain Logic裏實現的業務邏輯全部封裝一遍。
貧血模型，只有get和set。所有業務邏輯都在Business Logic層。
優點，更層次單項依賴。
缺點，不夠面向對象，領域對象知識作爲保存狀態和傳遞狀態使用，只有數據沒有行爲。
聚合
領域模型內的實體和值對象就好比個體，而能讓實體和值對象協同工作的組織就是聚合，它用來確保這些領域對象在實現共同的業務邏輯時，能保證數據的一致性。
1.高內聚、低耦合，它是領域模型中最底層的邊界，可以作爲拆分微服務的最小單位，但不建議對微服務過渡拆分。對性能有機制要求的場景，聚合可以獨立未一個微服務。
聚合根
1.是一個實體。
2.聚合的管理者，負責協調實體和值對象按照固定的業務規則協同完成共通的業務邏輯。
3.具有全局唯一標識，有獨立的生命週期。
4.一個聚合只有一個聚合根。
個人理解：
訂單->聚合根
訂單金額
訂單商品列表
訂單狀態等實體聚合爲一個聚合
聚合的一些設計原則
1.在一致性邊界內建模真正的不變。
聚合用來封裝真正的不變性，而不是簡單地將對象組合在一起。聚合內有一套不變的業務規則，各實體和值對象按照統一的業務規則運行，實現對象數據的一致性，邊界之外的任何東西都與該聚合無關，這就是聚合能實現業務高內聚的原因。
2.聚合設計的足夠小。
如果聚合設計得過大，聚合會因爲包含過多的實體，導致實體之間的管理過於複雜，高頻操作時會出現併發衝突或者數據庫鎖，最終導致系統可用性變差。而小聚合設計則可以降低由於業務過大導致聚合重構的可能性，讓領域模型更能適應業務的變化。
3.通過唯一標識引用其他聚合。
聚合之間的通過關聯外部聚合根ID的方式引用，而不是直接對象引用方式。外部聚合的對象放在聚合邊界內管理，容易導致聚合的邊界不清晰，也會增加結合直接的耦合度。
4.在邊界之外使用最終一致性。
聚合內數據強一致性嗎，而聚合之間的數據保障最終一致性，實現聚合之間的解耦。
5.通過應用層實現跨聚合的服務調用。
避免跨聚合的領域服務調用和跨聚合的數據庫表關聯（同時意味着跨聚合事務也是不推薦的？）