go - (Golang)整洁架构 - 谁应该做编排？

Question

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

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

GetHotelInfo 的逻辑是:

调用 GetHotelPropertyData() (位置、设施……)

调用 GetHotelPrice(hotel_id, dates…)

调用 GetHotelReviews(hotel_id)

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

选项 1 :

创建 3 个不同的存储库(HotelPropertyRepo、HotelPriceRepo、
HotelReviewsRepo)

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

选项 2 :

创建 3 个不同的存储库(HotelPropertyRepo、HotelPriceRepo、
HotelReviewsRepo)

创建 3 个不同的用例(GetHotelPropertyDataUseCase，
GetHotelPriceUseCase, GetHotelReviewsUseCase)

创建将协调前 3 个的 GetHotelInfoUseCase
用例。 (它也可以是 Controller ，但这是另一个话题)

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

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

Answer 1

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

马纳托指出:

关注 Acyclic Dependencies Principle (ADP) ，依存关系只指向圈内，不指向外，没有循环。

Controller 和 Presenter 依赖于用例输入端口和输出端口，它们被定义为接口(interface)，而不是特定的逻辑(细节)。由于Dependency Inversion Principle (DIP)，这是可能的(不知道外层的细节) .

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

存储库，

主持人:负责输出端口

interactor:负责Input Port，有一套具体应用业务规则的方法，依赖于repository和presenter接口(interface)。

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