(戈朗)清洁建筑-谁应该做编曲？

Question

我正试图了解以下两种选择中哪一种是正确的方法，以及原因。

假设我们有从网络调用的GetHotelInfo(hotel_id) API，直到控制器。

GetHotelInfo的逻辑是：

1. 调用GetHotelPropertyData() (位置、设施…)
2. 调用GetHotelPrice(hotel_id, dates…)
3. 调用GetHotelReviews(hotel_id)

一旦所有结果返回，处理并合并数据，并返回包含酒店所有相关数据的1个对象。

选项1

​

​

• 创建3个不同的存储库(HotelPropertyRepo、HotelPriceRepo、HotelReviewsRepo)
• 创建使用这3个存储库并返回最终结果的GetHotelInfo usecase。

选项2

​

​

• 创建3个不同的存储库(HotelPropertyRepo、HotelPriceRepo、HotelReviewsRepo)
• 创建3种不同的用例(GetHotelPropertyDataUseCase，GetHotelPriceUseCase，GetHotelReviewsUseCase)
• 创建GetHotelInfoUseCase，它将编排前面的三个用例。(它也可以是控制器，但这是一个不同的主题)

假设现在只有GetHotelInfo正在向网络公开，但也许在将来，我也会公开一些内部请求。

如果GetHotelInfo的实际逻辑不是三个端点的组合，而是10个端点，那么答案会有所不同吗？

Answer 1

您可以在Get()的"带GO的清洁建筑“中看到类似的方法(称为黑田马纳托 )

马纳托指出：

• 在无环依赖原理(ADP)之后，依赖点只指向圆圈内，而不是向外点，没有循环。
• 控制器和演示者依赖于用例输入端口和输出端口，它们被定义为接口，而不是特定的逻辑(细节)。这是可能的(不知道外层的细节)，多亏了依赖反演原理(DIP)。

​

​

这就是为什么在存储库manakuro/golang-clean-architecture中，Manato为用例层创建三层目录的原因：

• 储存库，
• 推荐人:负责输出端口
• interface :负责输入端口，根据存储库和演示器接口，提供一组特定应用程序业务规则的方法。

您可以使用该示例来调整您的情况，GetHotelInfo首先在hotel_interactor.go文件中声明，并取决于在hotel_repository中声明的特定业务方法，以及hotel_presenter中定义的响应。

Answer 2

是预期的中间参与者(用例类)调用其他的交互参与者。因此，这两种方法都遵循清洁架构原则。

但是，“可能在未来的”这一短语与良好的设计和体系结构实践背道而驰。

我们可以而且应该以最抽象的方式思考，这样我们才能更好地重用。但总是保持简单，避免不必要的复杂性。

如果GetHotelInfo的实际逻辑不是三个端点的组合，而是10个端点，那么答案会有所不同吗？

不，会一样的。但是，在设计API时，如果需要组合数十个端点，您应该开始考虑放置一个GraphQL层，而不是增加项目的复杂性。

Answer 3

清洁不是一个明确的术语。相反，您应该将更改的影响降到最低(添加或删除服务)。所谓“影响”，我指的不仅是成本和时间因素，还包括引入倒退的风险(破坏系统中不应该触及的另一个部分)。

为了最大限度地减少“变化的影响”，您可以将它们分割成不同的服务/有界的上下文，并且只允许通过事件进行交互。“控制器”将引发像“酒店信息请求”这样的事件(在共享总线上)，每个单独的服务(属性、价格和评论)将独立和异步地响应(可能在同一总线上)，让控制器聚合结果并将结果返回客户端，这可以在一段时间后完成。如果适当地编写结果聚合器，就可以添加新的“特性”，或者完全独立于其他特性删除现有特性。

为了改进这一点，您可以将每个上下文的读和写功能分离到它自己的上下文中，每个上下文都响应适当的事件。这将使您可以独立于读函数优化和缩放写函数。我们称之为CQRS。