DDD領域驅動實踐記錄

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

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

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

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

 

 如今該分析業務了，這個是難點，對接這種任務主要就是服務方api的調用和我方業務的調用。Domian應該是業務的體現，是不管應用層怎麼變，業務應該要能不多受影響。因而咱們將對接的業務放在這裏，將調用放到外部本來的應用層裏。這裏我畫了個圖，看樣子應該挺像的

 

 由於是一個小型的實踐產品，沒有複雜的業務，沒有複雜的交互，因此是很簡陋的了。

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

 

 

 

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

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