我試圖了解以下兩個選項中的哪一個是正確的方法以及為什么。假設(shè)我們有GetHotelInfo(hotel_id)從 Web 調(diào)用到 Controller 的 API。GetHotelInfo 的邏輯是：調(diào)用GetHotelPropertyData()（位置、設(shè)施……）調(diào)用GetHotelPrice(hotel_id, dates…)調(diào)用GetHotelReviews(hotel_id)一旦所有結(jié)果返回，處理并合并數(shù)據(jù)并返回包含酒店所有相關(guān)數(shù)據(jù)的 1 個對象。選項 1：創(chuàng)建 3 個不同的存儲庫（HotelPropertyRepo、HotelPriceRepo、HotelReviewsRepo）創(chuàng)建將使用這 3 個存儲庫并返回最終結(jié)果的 GetHotelInfo 用例。選項 2：創(chuàng)建 3 個不同的存儲庫（HotelPropertyRepo、HotelPriceRepo、HotelReviewsRepo）創(chuàng)建 3 個不同的用例（GetHotelPropertyDataUseCase、GetHotelPriceUseCase、GetHotelReviewsUseCase）創(chuàng)建將協(xié)調(diào)前 3 個用例的 GetHotelInfoUseCase。（它也可以是一個控制器，但這是一個不同的主題）假設(shè)現(xiàn)在只GetHotelInfo向 Web 公開，但也許在將來，我也會公開一些內(nèi)部請求。如果 GetHotelInfo 的實際邏輯不是 3 個端點的組合而是 10 個端點的組合，答案會不會有所不同？
3 回答
茅侃侃
TA貢獻1842條經(jīng)驗 獲得超21個贊
您可以在Manato Kuroda的“ Clean Architecture with GO ”中看到類似的方法（稱為Get()）
馬納托指出：
遵循非循環(huán)依賴原則（ADP），依賴在循環(huán)中只指向內(nèi)部，不指向外部，沒有循環(huán)。
Controller 和 Presenter 依賴于用例輸入端口和輸出端口，它們被定義為接口，而不是特定的邏輯（細節(jié)）。由于依賴倒置原則（DIP），這是可能的（不知道外層的細節(jié)） 。
這就是為什么在示例存儲庫manakuro/golang-clean-architecture中，Manato 為用例層創(chuàng)建了三層目錄：
存儲庫，
主持人：負責輸出端口
interactor：負責Input Port，有一套具體應(yīng)用業(yè)務(wù)規(guī)則的方法，依賴于repository和presenter接口。
您可以使用該示例來調(diào)整您的案例，GetHotelInfo首先在hotel_interactor.go文件中聲明，并取決于在中聲明的特定業(yè)務(wù)方法hotel_repository，以及在中定義的響應(yīng)hotel_presenter
白板的微信
TA貢獻1883條經(jīng)驗 獲得超3個贊
期望Interactors（用例類）調(diào)用其他interactors。因此，這兩種方法都遵循清潔架構(gòu)原則。
但是，“也許在未來”這句話與良好的設(shè)計和架構(gòu)實踐背道而馳。
我們可以而且應(yīng)該以最抽象的方式思考，以便我們可以支持重用。但始終保持簡單，避免不必要的復雜性。
如果 GetHotelInfo 的實際邏輯不是 3 個端點的組合而是 10 個端點的組合，答案會不會有所不同？
不，它會是一樣的。但是，在您設(shè)計 API 時，如果您需要組合數(shù)十個端點，您應(yīng)該開始考慮放置一個 GraphQL 層，而不是增加項目的復雜性。
桃花長相依
TA貢獻1860條經(jīng)驗 獲得超8個贊
清潔不是一個定義明確的術(shù)語。相反，您的目標應(yīng)該是盡量減少更改（添加或刪除服務(wù)）的影響。我所說的“影響”不僅是指成本和時間因素，還包括引入回歸的風險（破壞系統(tǒng)的不同部分，你不應(yīng)該接觸）。
為了最大限度地減少“變化的影響”，您可以將它們拆分為單獨的服務(wù)/有界上下文，并只允許通過事件進行交互?！翱刂破鳌睍l(fā)一個事件（在共享總線上），如“酒店信息請求”，每個單獨的服務(wù)（屬性、價格和評論）將獨立且異步地響應(yīng)（可能在同一總線上），讓控制器匯總結(jié)果并將它們返回給客戶端，這可以在一段時間后完成。如果您對結(jié)果聚合器進行適當?shù)木幋a，則可以添加新的“功能”或完全獨立于其他功能刪除現(xiàn)有功能。
為了改進這一點，您可以將每個上下文的讀取和寫入功能分離到它自己的上下文中，每個上下文都響應(yīng)適當?shù)氖录?。這將允許您獨立于讀取功能優(yōu)化和擴展寫入功能。我們稱之為 CQRS。
- 3 回答
- 0 關(guān)注
- 150 瀏覽
添加回答
舉報
0/150
提交
取消