我試圖了解以下兩個選項中哪一個是正確的方法以及原因。假設我們有GetHotelInfo(hotel_id)從 Web 到控制器調用的 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 個用例。（它也可以是控制器，但這是另一個主題）假設現在僅GetHotelInfo暴露在 Web 上，但也許將來我也會暴露一些內部請求。如果 GetHotelInfo 的實際邏輯不是 3 個端點的組合而是 10 個端點的組合，答案會有所不同嗎？
3 回答
PIPIONE
TA貢獻1829條經驗 獲得超9個贊
您可以在Manato KurodaGet()的“?Clean Architecture with GO?”中看到類似的方法（稱為）
馬納托指出：
遵循非循環依賴原則（ADP），依賴關系只在循環中指向內，而不指向外，不存在循環。
Controller 和 Presenter 依賴于用例輸入端口和輸出端口，它們被定義為接口，而不是特定的邏輯（細節）。由于依賴倒置原則（DIP），這是可能的（不知道外層的細節）。
這就是為什么在示例存儲庫中manakuro/golang-clean-architecture，Manato 為用例層創建了三個目錄：
存儲庫，
主持人：負責輸出端口
interactor：負責Input Port，擁有一組具體應用業務規則的方法，依賴于repository和presenter接口。
您可以使用該示例來調整您的案例，GetHotelInfo首先在文件中聲明hotel_interactor.go，并根據 中聲明的特定業務方法hotel_repository以及 中定義的響應hotel_presenter
MYYA
TA貢獻1868條經驗 獲得超4個贊
預期交互器（用例類）調用其他交互器。因此，這兩種方法都遵循清潔架構原則。
但是，“也許在未來”這句話違背了良好的設計和架構實踐。
我們可以而且應該以最抽象的方式思考，以便我們可以支持重用。但始終保持事情簡單并避免不必要的復雜性。
如果 GetHotelInfo 的實際邏輯不是 3 個端點的組合而是 10 個端點的組合，答案會有所不同嗎？
不，會是一樣的。然而，當您設計 API 時，如果您需要數十個端點的組合，您應該開始考慮放置 GraphQL 層，而不是增加項目的復雜性。
江戶川亂折騰
TA貢獻1851條經驗 獲得超5個贊
清潔并不是一個明確定義的術語。相反，您應該致力于最大限度地減少變更（添加或刪除服務）的影響。我所說的“影響”不僅指成本和時間因素，還指引入回歸的風險（破壞系統中您不應該接觸的不同部分）。
為了最大限度地減少“變化的影響”，您可以將它們拆分為單獨的服務/有界上下文，并僅允許通過事件進行交互。“控制器”將引發一個事件（在共享總線上），例如“酒店信息請求”，并且每個單獨的服務（屬性、價格和評論）將獨立且異步地響應（可能在同一總線上），從而使控制器匯總結果并將其返回給客戶端，這可以在一段時間后完成。如果您對結果聚合器進行適當的編碼，則可以完全獨立于其他功能添加新“功能”或刪除現有功能。
為了改進這一點，您可以將每個上下文的讀取和寫入功能分離到其自己的上下文中，每個上下文都響應適當的事件。這將允許您獨立于讀取功能來優化和擴展寫入功能。我們稱之為 CQRS。
- 3 回答
- 0 關注
- 201 瀏覽
添加回答
舉報
0/150
提交
取消