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