談架構設計中DDD思想的運用

首先，描述一下個人業務場景及項目分層結構，非標準DDD(其實我不以爲有標準)，只是思考的時候有帶入DDD思想。

 

業務場景：這是一個ERP系統對中臺提供的接口項目，倉儲操做大多都是存儲過程去完成的。

 

項目結構，如圖：

 

 

WebAPI層：這個不用多說了，入口。

DTO層：增長數據傳入傳出對象，和領域model、實體model區分。（要不要圍繞領域model或從現有系統中提取領域model看實際業務狀況，拿我目前這個項目來講，得不償失。）

Services層：業務服務層（能夠命名成BizServices區分），主要寫一些業務邏輯，而後調用領域服務層DomainServices（若是有的話），若是沒有，則直接調用倉儲服務，進行持久化操做。

Repository層：打算用dapper進行持久化操做，對外提供RepositoryService。我這裏比較特殊，下面講。

 

融合了一部分DDD思想後，項目結構和流程原本應該是這樣：Request→WebAPI→DTO→BizServices→DomainServices→RepositoryService→DTO→Response。

一個Request對應一個BizServices可能對應多個DomainServices可能對應多個RepositoryService

實際是這樣的：Request→WebAPI→DTO→BizServices→RepositoryService/.DomainService→DTO→Response。

 

那麼，問題就來了：

由於DomainServices應該作的聚合Repository.Service的操做實際都在存儲過程當中進行了，但Repository.Service同時完成了Repository.Service和DomainServices一塊兒乾的事情，產生了越界，這個無論我把DomainServices拿出去放外面一層，實際狀況都如上所述。

癥結就是存儲過程幹了DomainServices的事情，不要跟我說把存儲過程的事情拿出來從新寫一遍，你覺得面對不知道有沒有1000個的存儲過程我沒認真想過嘛，因此Repository.Service.DomainServices就是爲了標註這種歧義。

 

哈哈哈，說完了，不知道你們有沒有看明白，望獲得高人指點。