首先，描述一下我的業務場景及項目分層結構，非標準DDD(其實我不覺得有標準)，只是思考的時候有帶入DDD思想。 業務場景：這是一個ERP系統對中台提供的介面項目，倉儲操作大多都是存儲過程去完成的。 項目結構，如圖： WebAPI層：這個不用多說了，入口。 DTO層：增加數據傳入傳出對象，和領域mod ...
首先，描述一下我的業務場景及項目分層結構，非標準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就是為了標註這種歧義。
哈哈哈，說完了，不知道大家有沒有看明白，望得到高人指點。
