go - (Golang) Clean Architecture - 谁来编排？

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

假设我们有从 Web 调用到 Controller 的 GetHotelInfo(hotel_id) 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)

创建 GetHotelInfoUseCase 来协调前 3 个
用例。 (它也可以是一个 Controller ，但那是一个不同的话题)

假设现在只有 GetHotelInfo 暴露在 Web 上，但也许在 future ，我也会暴露一些内部请求。

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

最佳答案

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

马纳托指出:

跟在 Acyclic Dependencies Principle (ADP) 之后，依赖只指向圆内，不指向外，没有循环。

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

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

存储库，

Presenter:负责输出端口

交互器:负责Input Port，有一套具体应用业务规则的方法，取决于repository和presenter接口(interface)。

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

关于go - (Golang) Clean Architecture - 谁来编排？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/60732673/