雖然很早之前就已經(jīng)了解過DDD相關(guān)的內(nèi)容了，但一方面網(wǎng)上理論知識(shí)太過碎片化導(dǎo)致難以理解，另一方面實(shí)踐內(nèi)容太少導(dǎo)致想動(dòng)手的時(shí)候無從下手。于是就漸漸淡忘了這方面實(shí)踐的念頭。

最近重新了解了DDD相關(guān)的知識(shí)，依舊是云里霧里，總感覺落實(shí)實(shí)在是困難，對領(lǐng)域模型，上下文限定什么的太過模糊，基本都很主觀，依舊難以理解。甚至有想放棄的念頭。

這時(shí)候剛好分配了一個(gè)對接電子發(fā)票的任務(wù)，需要新建個(gè)類庫，我就在想能不能在實(shí)踐中不管對不對先試試一個(gè)小型的DDD呢？

emmm。。先根據(jù)DDD分層架構(gòu)的傳統(tǒng)4層分層。User Interface放在類庫不合適，忽略。Application目前內(nèi)容應(yīng)該很簡單，而且不能更改原來的項(xiàng)目結(jié)構(gòu)，忽略。 大頭來了，Domain 這個(gè)是核心必須要有，?Infrastructure可以有。于是項(xiàng)目結(jié)構(gòu)就是決定了

?

?現(xiàn)在該分析業(yè)務(wù)了，這個(gè)是難點(diǎn)，對接這種任務(wù)主要就是服務(wù)方api的調(diào)用和我方業(yè)務(wù)的調(diào)用。Domian應(yīng)該是業(yè)務(wù)的體現(xiàn)，是無論應(yīng)用層怎么變，業(yè)務(wù)應(yīng)該要能很少受影響。于是我們將對接的業(yè)務(wù)放在這里，將調(diào)用放到外部原本的應(yīng)用層里。這里我畫了個(gè)圖，看樣子應(yīng)該挺像的

?

?因?yàn)槭且粋€(gè)小型的實(shí)踐產(chǎn)品，沒有復(fù)雜的業(yè)務(wù)，沒有復(fù)雜的交互，所以是很簡陋的了。

相應(yīng)的目錄應(yīng)該是這樣的了

?

?

?

?我以前一直以為像是一個(gè)api的返回參數(shù)與接受參數(shù)是entity，最近寫的時(shí)候忽然覺得，其實(shí)這應(yīng)該算Values，畢竟這個(gè)不影響真正的業(yè)務(wù)內(nèi)容，而且只是傳遞值使用的，所以將之劃分為了Values里面。

根據(jù)這個(gè)流程，作為聚合根的Business和外部交互，理論上應(yīng)該是正常的。這個(gè)小小的實(shí)踐，算是這一段學(xué)習(xí)的記錄吧

轉(zhuǎn)載于:https://www.cnblogs.com/lgl-blogs/p/11533620.html

總結(jié)

以上是生活随笔為你收集整理的DDD领域驱动实践记录的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。