雖然很早之前就已經了解過DDD相關的內容了，但一方面網上理論知識太過碎片化導致難以理解，另一方面實踐內容太少導致想動手的時候無從下手。于是就漸漸淡忘了這方面實踐的念頭。

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

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

emmm。。先根據DDD分層架構的傳統4層分層。User Interface放在類庫不合適，忽略。Application目前內容應該很簡單，而且不能更改原來的項目結構，忽略。 大頭來了，Domain 這個是核心必須要有，?Infrastructure可以有。于是項目結構就是決定了

?

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

?

?因為是一個小型的實踐產品，沒有復雜的業務，沒有復雜的交互，所以是很簡陋的了。

相應的目錄應該是這樣的了

?

?

?

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

根據這個流程，作為聚合根的Business和外部交互，理論上應該是正常的。這個小小的實踐，算是這一段學習的記錄吧

轉載于:https://www.cnblogs.com/lgl-blogs/p/11533620.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。