零散記錄，隨想隨記，在適當的時候再做整合：
問題一：對於數據或輸入參數的校驗應該放到應用層還是領域層？
在編寫程序時，少不了對輸入參數的校驗。
第一可以減少異常場景，另外也可以節省不必要的執行邏輯，從這個角度講參數的校驗應該儘量靠前，如果參數是異常的話，應該儘早返回給調用方，所以放在應用層的最前端比較合適。
但如果把參數合法性理解成爲領域對象的行爲，也就是說領域對象是最瞭解輸入參數校驗規則的，那麼就應該把參數校驗邏輯放在領域層。並且，對於調用領域對象的調用方來說，這樣是安全可靠的，同時也減少了重複校驗的可能性。
結論：不是原則性問題，可以通過定於規範來統一行爲，但是一定要有地方定義參數的校驗邏輯，無論是在接口文檔，還是在領域對象的註釋中，並且保證這是唯一定義參數校驗邏輯的地方。
問題二：對於事務的控制應該放在哪裏？
比較重要，核心的問題。事務的定義：是指作爲單個邏輯工作單元執行的一系列操作，要麼完全地執行，要麼完全地不執行。
有幾條原則：1. 聚合根首先是原子的，即聚合根內部的操作是原子的；
結論：目前看，事務應該放在應用層來做，由應用層來統一規劃事務的範圍，畢竟事務的範圍是由業務最終決定的。
問題三：領域邊界如何界定？
之前一直在糾結一個問題：兩個系統交互時，可能會用到同樣的對象，例如A系統調用B系統獲取User信息，A和B系統都需要定義User的數據結構，那麼這個User的數據結構是分別由A和B分別維護，還是在一個Common包中維護？
如果由A和B分別維護，則當User發生變化時，A和B要協調同步修改，這裏可能存在沒有同步的問題；如果在Common包中維護，而A和B對User的定義有可能不完全一樣，所以還需要在A和B中分別再創建UserA和UserB，以區分兩者的不同，產生了冗餘。
結論：需要結合具體場景來使用。如果把User單純定義爲傳輸結構的定義而不具備領域含義（即將其定義爲應用層概念），那麼在Common包中定義比較合適。但如果爲了精簡結構，User不僅作爲傳輸結構，同時也包含領域意義（那麼A和B對User的定義需要在各自的領域範圍內賦能，其結構有相似但含義完全不同，比如A中是User，B中可能是Customer），那麼就一定要由A和B分別定義了。