1）：從使用者處接收命令操作，改變底層系統狀態。
2）：從使用者處接收查詢操作，將底層系統狀態以合適的形式呈現給使用者。
遮蔽資料儲存細節，這些資料**可以是資料庫（mysql，nosql）、搜尋引擎、檔案系統、也可以是其他微服務等。向其他層提供 通用的 技術能力(比如工具類,第三方庫類支援,常用基本配置,資料訪問底層實現，
基礎實施層主要包含以下的內容:
1）實體儲存時，倉庫層的入參不能為基礎的資料表物件,入參物件應設定為實體。
2）其他命令操作時，應用層呼叫倉庫層儲存資料，入參可根據實際的情況傳入對應的實體或入參命令物件（比如只是修改資料的個別欄位可傳入修改命令，修改大量字段資訊，傳入實體）。
3）領域層只做純記憶體的業務規則操作，原則上不能在領域層中直接呼叫倉庫層儲存資料。
4）應用層的出參設定為dto或基礎資料物件（如主鍵編碼），不能直接返回實體；
5）當乙個業務涉及到多個實體時，不能在乙個實體中直接呼叫另外乙個實體（聚合根可呼叫內部的子實體），應該基於應用層或第三方領域服務協調處理。
6）明確各個層的職能，不要混用。
7）領域層做業務規則處理，針對不同的規則場景，建議採用策略設計模式，多用設計模式實現領域服務便於系統後續的擴充套件和調整。
8）涉及到主子記錄的情況，一般建立聚合根，基於聚合根統一的儲存資料。
9）當業務需要多個實體同時處理時，可在應用層統一加上事務管理。
10）針對一些基礎配置的需求，無業務邏輯，或比較簡單的業務（crud），採用ddd模式也很費力，此刻不一定非要使用ddd模式。
領域驅動設計系列（一） 為何要領域驅動設計？
領域驅動設計最近貌似開始火起來了，越來越多的人開始認識到領域設計的重要性，從我做過的專案來看，似乎歐洲已經有很多的公司開始實施領域驅動設計了，我看領域驅動設計也有些時間了，但是網上不管是文章還是 都顯得太過 高大上 一談領域驅動設計，一大堆的概念一股腦的給你上上來，搞的有點暈頭轉向，而我想在一些中小...
領域驅動設計之我見 領域業務
談到領域驅動設計 ddd 人們很容易想到如下這張圖，那麼是不是你的軟體做了如下的分層設計就是領域驅動設計的了？顯然不是，以下分層只能說明的軟體做了分層架構，領域驅動設計的核心在領域模型，領域模型的核心在業務知識。如果能夠採用物件導向思維將業務抽象為恰當的模型，不管用什麼架構都稱得上領域驅動設計。在大...
領域驅動設計 Understanding DDD
無論有沒有軟體支援,無論軟體是好是壞,世界各地每個領域每天都發生著數以億計可以理解的業務 領域驅動設計是一種設計方法,試 決的問題是軟體的難以理解,難以演化.採用的方法是圍繞業務概念來構建模型.不過你也可以從兩個角度來理解領域驅動設計 作為設計結果的ddd和作為開發方法的ddd,即 what and...