前言
大家好，我是一名普普通通的后端研發(fā)。很久沒有來過簡書了，很高興回來~
領(lǐng)域驅(qū)動設(shè)計（Domain Driven Design,DDD）是我大學開始就接觸的概念，但一直到工作這么久了，卻一直感覺像是霧里看花，仿佛懂了，卻一直找不到說服自己用它的理由。
一年前，我又一次開始重新審視這個概念。終于，這一次，我結(jié)合實際項目場景和DDD的理念后，分析出一個以DDD為基礎(chǔ)的編碼規(guī)范。它不是一個很具象的技術(shù)組件，而更側(cè)重于領(lǐng)域的分析，代碼結(jié)構(gòu)的編排等。
作為第一篇文章，我直接見山，介紹它在開發(fā)中的改變以及所帶來的優(yōu)勢。
開發(fā)中的改變
- 讀寫隔離：查詢操作與命令操作（增刪改）通過文件（如Java的class）進行強制隔離
- 充血模型：實體類中允許出現(xiàn)行為操作，如
order.cancel()
帶來的優(yōu)勢
讀寫隔離
- 對查詢來說，采用
ReadOnly=true，從代碼規(guī)范上“強制”保證查詢的純凈性與無害性 - 系統(tǒng)真正的流程變動都在命令，所以保證業(yè)務(wù)流程的聚焦，不受到查詢的干擾
- 查詢【重性能-輕事務(wù)】，修改則反之，不同的模塊隔離，更便于框架進行統(tǒng)一優(yōu)化，比如代碼復用性，AOP優(yōu)化，安全權(quán)限等等
- 如果為了性能考慮，要進行物理持久化層面的讀寫分離，也很方便
充血模型
- 明確領(lǐng)域責任劃分，實體更具有實際意義，更符合面向?qū)ο蟮脑O(shè)計理念；
- 在長事務(wù)，復雜處理的過程中，可讀性更強；
歡迎拍磚
這個規(guī)范，僅僅是參考DDD的部分思路，并非完全照搬DDD，因為領(lǐng)域分析里有太多太多概念，而且由于是一種非常抽象的分析模式，無法量化，更難形成標準。所以，我在這里只是吸取了其中一部分思路，然后以充血模型為基礎(chǔ)，并給出一些可以量化的標準，來讓團隊更容易將這個規(guī)范落地。
所以，某成程度來說，它或許已經(jīng)不是DDD的范疇了。
總之：
- 我寫下本系列的幾篇小文，算不上什么高深的技術(shù)文章，更多的是一個探討與嘗試，因為我個人真的挺喜歡這種分析和編碼方式，所以想分享給大家；
- 而正式由于DDD的思維方式和編碼方式和常規(guī)做法的差距較大，很容易讓大家無法短時間適應，但我恰恰就想通過這個過程，了解大家的反饋和質(zhì)疑，因為我也想知道，這個東西，真正落地，還有哪些困難；
- 所以，歡迎大家，文明拍磚，哈哈，如果有問題，能夠給出具體的實際例子進行討論更好。
感謝！
從下一篇開始進入正題：領(lǐng)域分析基礎(chǔ)
