微服務DDD CQRS

Question

我一直在閱讀有關DDD和微服務的信息。 通過使用CQRS部分的用例開始進行原型設計。 該用例是一款運動足球應用程序，其中包含視頻，新聞，樂譜和主頁。 在此，我確定了域和有界上下文

1. 新聞

2. 影片

3. 比分

4. 主頁

首先，3個域完全相互獨立。

現在，主頁域要求。 1.得分部分2.視頻部分3.內容部分

內容部分：它有自己的數據庫

視頻部分：它將使HTTP調用視頻服務並獲取數據

評分部分：它將使HTTP調用評分服務並獲取數據

我的問題是首頁域名。 我發現它與其他服務高度結合，並且不是獨立的。

如何設計主頁域？

Answer 1

我發現它與其他服務高度結合，並且不是獨立的。

是。

您可以通過仔細考慮故障模式來提高獨立性。 當相關數據權限不可用時，UI元素應如何表現。 例如，如果遠程授權機構沒有及時響應，則可以使主頁僅顯示“數據不可用”消息。 或者，您可以讓主頁顯示一些過時數據的緩存副本。 始終使用緩存的數據來呈現響應甚至在后台進行緩存更新時，甚至可能是有意義的。

您可以使用一些技術來減少服務之間的耦合。
Udi Dahan在UI合成技術的保護下描述了一種方法。 他的想法是，使用小部件之類的元素來封裝顯示邏輯和失敗模式。

底層的機制並沒有真正的不同。 當數據不可用時，小部件會遇到我們以前遇到的所有相同問題。 但是它的作用是分離出屬於不同團隊的兩個問題（當窗口小部件不可用時您將做什么，當數據不可用時您將做什么）：首頁團隊可以決定要做什么當窗口小部件不可用（可能使用了緩存的副本）時，服務團隊可以決定在窗口小部件無法到達后備數據（窗口小部件具有自己的過時數據緩存）時該怎么做。

沒有魔法； 您擁有分布式系統，其結果是您需要在設計中考慮以下事實：遠程進程並非總是可用。