我一直在阅读有关 DDD 和微服务的文章。通过 CQRS 部分的用例开始原型设计。用例是一个体育足球应用程序，其中包含视频、新闻、比分和主页。在此，我已经确定了域和有界上下文，它们是
消息
视频
分数
主页
首先，3 个域完全相互独立。
现在，主页域要求。1. 乐谱部分 2. 视频部分 3. 内容部分
内容部分：它有自己的数据库
视频部分：它将使HTTP调用视频服务并获取数据
Score 部分：它将通过 HTTP 调用 Score 服务并获取数据
我的问题是主页域。我发现它与其他服务高度耦合并且不是独立的。
如何设计主页域？
我发现它与其他服务高度耦合并且不是独立的。
是的。
您可以通过仔细考虑故障模式来提高独立性；当相关数据权限不可用时，UI 元素应该如何表现。例如，如果远程机构没有及时响应，您可以让主页简单地显示“数据不可用”消息。或者，您可以让主页显示一些过时数据的缓存副本。始终使用缓存数据呈现响应甚至可能是有意义的，缓存的更新发生在后台。
您可以使用一些技术来减少服务之间的耦合。
Udi Dahan 描述了一种方法，属于UI 组合技术。他的想法是你使用一个元素，比如一个小部件，来封装显示的逻辑和故障模式。
底层机制并没有那么不同。当数据不可用时，该小部件具有我们之前遇到的所有相同问题。但它所做的是分离出属于不同团队的两个问题（当小部件不可用时你会做什么，当数据不可用时你会做什么）：主页团队决定做什么当小部件不可用时（可能使用了缓存副本），服务团队将决定当小部件无法访问支持数据时该怎么做（也许小部件有自己的陈旧数据缓存）。
没有魔法；你有一个分布式系统，结果是你需要在设计中考虑远程进程并不总是可用的事实。