前言
大家好界拦，我是一名普普通通的后端研發(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)化，比如代碼復(fù)用性曹阔，AOP優(yōu)化半开，安全權(quán)限等等
- 如果為了性能考慮，要進行物理持久化層面的讀寫分離赃份，也很方便
充血模型
- 明確領(lǐng)域責任劃分寂拆，實體更具有實際意義，更符合面向?qū)ο蟮脑O(shè)計理念抓韩；
- 在長事務(wù)纠永，復(fù)雜處理的過程中，可讀性更強谒拴；
歡迎拍磚
這個規(guī)范渺蒿，僅僅是參考DDD的部分思路，并非完全照搬DDD彪薛，因為領(lǐng)域分析里有太多太多概念茂装，而且由于是一種非常抽象的分析模式，無法量化善延，更難形成標準少态。所以，我在這里只是吸取了其中一部分思路易遣，然后以充血模型為基礎(chǔ)彼妻，并給出一些可以量化的標準，來讓團隊更容易將這個規(guī)范落地豆茫。
所以侨歉，某成程度來說，它或許已經(jīng)不是DDD的范疇了揩魂。
總之：
- 我寫下本系列的幾篇小文幽邓，算不上什么高深的技術(shù)文章，更多的是一個探討與嘗試火脉，因為我個人真的挺喜歡這種分析和編碼方式牵舵，所以想分享給大家；
- 而正式由于DDD的思維方式和編碼方式和常規(guī)做法的差距較大倦挂，很容易讓大家無法短時間適應(yīng)畸颅，但我恰恰就想通過這個過程，了解大家的反饋和質(zhì)疑方援，因為我也想知道没炒，這個東西，真正落地犯戏，還有哪些困難送火；
- 所以祖很，歡迎大家，文明拍磚漾脂，哈哈假颇，如果有問題，能夠給出具體的實際例子進行討論更好骨稿。
感謝笨鸡！
從下一篇開始進入正題：領(lǐng)域分析基礎(chǔ)
