2016-06-14 53 views
1

我有一個有界的上下文與應用程序服務暴露與DTO的應用程序用例。DDD有界的上下文集成 - 應用程序服務vs域服務與存儲庫

有界的上下文還包括一個域服務暴露域名用例與豐富的域對象。應用程序服務是域服務的「客戶端」。

最後,允許域對象持久化的存儲庫。

該域中存在其他有界上下文,擁有有界上下文的團隊之間的關係是客戶/供應商,因此團隊對齊相同的目標並可以合作將需要的用例展示給其他有界上下文。

在這種情況下,「客戶有限上下文」應該連接到「供應商有限上下文」?

「供應商有限上下文」可以直接訪問存儲庫或暴露「供應商有限上下文」的富域對象的域服務嗎? (在「客戶有限上下文」中使用ACL來屏蔽「供應商有限上下文」在域中泄漏)。我不確定這種方法是否合適,因爲域重構會破壞所有ACL並需要維護。我知道這是ACL的目標,但是......

或者,「消費者有限上下文」最好只連接到「供應商有限上下文」的應用服務,公開的DTO暴露在哪裏? (不需要ACL)。我不確定這種方法是否合適,因爲它強制應用服務模擬域服務僅用作接入點,即使該用例顯然是域用例。

有沒有意見?任何人都嘗試了兩種方法中的一種,並且有好的/不好的經歷?

我無法從Vaughn Vernon的書或Scott Millett的書中找到明確的答案。

回答

1

兩個團隊應該合作爲供應商BC定義一個API。不要直接連接到其他BC應用程序服務甚至模型。

API通常是作爲REST API實現的,但從您的問題來看,您聽起來像是將多個BC集成到一個應用程序中。如果是這種情況,那麼您應該將API定義爲接口庫。

接口庫應該版本化和記錄。應該由供應商團隊維護,消費者團隊根據他們的需求提出變更請求。

如果供應商BC有非常簡單的模型,只能通過API公開域模型本身。在所有其他情況下,定義封裝所需用例的應用程序服務是有意義的。然後,只有這些應用服務將作爲API公開。

+0

在模型非常簡單的情況下,您是否也可以考慮將存儲庫的訪問直接暴露給其他有界上下文? 對於讓消費者有界的上下文來管理和決定數據庫事務作用域的配置方式,而不是讓供應商上下文以所有消費者上下文的「一般」方式對其進行管理,這可能會有用嗎? –

+0

我試圖避免它,就像我試圖避免直接暴露域模型一樣。您當然可以採取這種方法,但請注意,這會導致兩個BC之間的耦合度非常高。不要避免額外的應用服務,因爲它們看起來像很多代碼 - 它們增加了一個重要的抽象層,實現和維護它們通常是直接的。 – theDmi

+0

謝謝你的建議! –