(Golang) 清晰的架构 - 谁应该负责设计？

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《(Golang) 清晰的架构 - 谁应该负责设计？》，聊聊，我们一起来看看吧！

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

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

GetHotelInfo的逻辑是：

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

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

选项 1：

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

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

选项 2：

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

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

• 创建 GetHotelInfoUseCase 来协调前 3 个用例 用例。 （它也可以是控制器，但那是另一个主题）

假设现在只有 GetHotelInfo 暴露在网络上，但也许将来我也会暴露一些内部请求。

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

解决方案

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

马纳托指出：

• 在Acyclic Dependencies Principle (ADP)之后，依赖项仅在循环中指向内，而不指向外且不循环。
• Controller 和 Presenter 依赖于用例输入端口和输出端口，它们被定义为接口，而不是特定的逻辑（细节）。感谢 Dependency Inversion Principle (DIP)，这是可能的（不知道外层的详细信息）。

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

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

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

本篇关于《(Golang) 清晰的架构 - 谁应该负责设计？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！