(1) 基於領域分析設計的架構規範 - 改變與優點

本系列目錄：

1. 改變與優點
2. 領域分析基礎
3. 讀寫隔離
4. 充血模型之實體
5. 充血模型之Service
6. 關於重構與落地

前言

你們好，我是一名普普統統的後端研發。

領域驅動設計（Domain Driven Design,DDD）是我大學開始就接觸的概念，但一直到工做這麼久了，卻一直感受像是霧裏看花，彷彿懂了，卻一直找不到說服本身用它的理由。

一年前，我又一次開始從新審視這個概念。終於，這一次，我結合實際項目場景和DDD的理念後，分析出一個以DDD爲基礎的編碼規範。它不是一個很具象的技術組件，而更側重於領域的分析，代碼結構的編排等。

做爲第一篇文章，我直接見山，介紹它在開發中的改變以及所帶來的優點。

開發中的改變

1. 讀寫隔離：查詢操做與命令操做（增刪改）經過文件（如Java的class）進行強制隔離
2. 充血模型：實體類中容許出現行爲操做，如order.cancel()

帶來的優點

讀寫隔離

1. 對查詢來講，採用ReadOnly=true，從代碼規範上「強制」保證查詢的純淨性與無害性
2. 系統真正的流程變更都在命令，因此保證業務流程的聚焦，不受到查詢的干擾
3. 查詢【重性能-輕事務】，修改則反之，不一樣的模塊隔離，更便於框架進行統一優化，好比代碼複用性，AOP優化，安全權限等等
4. 若是爲了性能考慮，要進行物理持久化層面的讀寫分離，也很方便

充血模型

1. 明確領域責任劃分，實體更具備實際意義，更符合面向對象的設計理念；
2. 在長事務，複雜處理的過程當中，可讀性更強；
3. 因爲每個命令操做被有序的概括到充血模型中，在追蹤實體行爲時，很是方便；

歡迎拍磚

這個規範，僅僅是參考DDD的部分思路，並不是徹底照搬DDD，由於領域分析裏有太多太多概念，並且因爲是一種很是抽象的分析模式，沒法量化，更難造成標準。因此，我在這裏只是吸收了其中一部分思路，而後以充血模型爲基礎，並給出一些能夠量化的標準，來讓團隊更容易將這個規範落地。

因此，某成程度來講，它或許已經不是DDD的範疇了。

總之：

• 我寫下本系列的幾篇小文，算不上什麼高深的技術文章，更多的是一個探討與嘗試，由於我我的真的挺喜歡這種分析和編碼方式，因此想分享給你們；
• 而正式因爲DDD的思惟方式和編碼方式和常規作法的差距較大，很容易讓你們沒法短期適應，但我偏偏就想經過這個過程，瞭解你們的反饋和質疑，由於我也想知道，這個東西，真正落地，還有哪些困難；
• 因此，歡迎你們，文明拍磚，哈哈，若是有問題，可以給出具體的實際例子進行討論更好。

感謝！ 從下一篇開始進入正題：領域分析基礎