go - （Golang）清洁架构 - 谁应该做编排？

Question

我试图了解以下两个选项中的哪一个是正确的方法以及为什么。

假设我们有GetHotelInfo(hotel_id)从 Web 调用到 Controller 的 API。

GetHotelInfo 的逻辑是：

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

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

选项 1：

• 创建 3 个不同的存储库（HotelPropertyRepo、HotelPriceRepo、HotelReviewsRepo）

• 创建将使用这 3 个存储库并返回最终结果的 GetHotelInfo 用例。

选项 2：

• 创建 3 个不同的存储库（HotelPropertyRepo、HotelPriceRepo、HotelReviewsRepo）

• 创建 3 个不同的用例（GetHotelPropertyDataUseCase、GetHotelPriceUseCase、GetHotelReviewsUseCase）

• 创建将协调前 3 个用例的 GetHotelInfoUseCase。（它也可以是一个控制器，但这是一个不同的主题）

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

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

标签： gomodel-view-controllerarchitectureuse-caseclean-architecture

Answer 1

您可以在Manato Kuroda的“ Clean Architecture with GO ”中看到类似的方法（称为Get()）

马纳托指出：

• 遵循非循环依赖原则（ADP），依赖在循环中只指向内部，不指向外部，没有循环。
• Controller 和 Presenter 依赖于用例输入端口和输出端口，它们被定义为接口，而不是特定的逻辑（细节）。由于依赖倒置原则（DIP），这是可能的（不知道外层的细节） 。

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

• 存储库，
• 主持人：负责输出端口
• interactor：负责Input Port，有一套具体应用业务规则的方法，依赖于repository和presenter接口。

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