我的應用程式具有以下檔案夾結構
app
core
features
feature1
domain
entities
entity1
entity2
entity3
entity4
entity5
entity6
data
models
model1
model2
model3
model4
model5
model6
presentation
feature2
domain
entities
entity1
entity2
entity3
entity4
entity5
entity6
data
models
model1
model2
model3
model4
model5
model6
presentation
兩種功能的模型 1 到 6 完全相同，并且隨著應用程式的擴展，還會有更多功能。這變得難以維護。干凈的架構是否允許跨多個功能共享模型和物體？那會通過核心檔案夾完成嗎？
uj5u.com熱心網友回復：
是的，你可以，你也許不應該這樣做。
是的，因為干凈的架構沒有對此發表宣告。只要遵守依賴規則，您就符合干凈的架構。
但是您可能不應該這樣做，因為您應該考慮其他原則和考慮因素。
首先，你應該問問自己這是否違反了單一責任原則。有時事情看起來一樣，但實際上并不是重復的代碼。他們看起來一樣更像是一個意外。問題是“誰是變更觸發器？”。通常，功能會因不同的原因而改變，因此功能用例和物體也會因不同的原因而改變。如果是這樣，您不應該在它們之間共享模型。
其次，從DDD（領域驅動設計）的角度來看，這些特征可以位于不同的有界背景關系中。在這種情況下，您可以擁有兩個具有相同名稱的物體，但它們在不同的背景關系中具有不同的含義。因此，模型具有不同的屬性和不同的方法。
如果您決定共享這些模型，您應該仔細查看它們，并掃描它們的屬性和方法。是否有專門用于一項功能的屬性和方法？如果是這樣，您可能會混淆擔憂。
最后，如果您遇到諸如“呃，我們在這里改變了一些東西并在那里破壞了一些東西”之類的問題，您應該重新考慮共享一些代碼是否是一個好方法。代碼共享總是耦合代碼，因為所有客戶端都依賴于共享代碼。這是重復（維護成本）和依賴關系之間的權衡。SRP 等原則可幫助您做出有根據的猜測。
uj5u.com熱心網友回復：
我假設您正在
然后，在所有這些頂級目錄中（不包??括/core專門用于 API 客戶端、路由器等的目錄），每個功能都有檔案夾。例如：authentication、settings、posting等。
然后，這是重要的一點，在每個功能拆分目錄（例如：/domain、、/presentation等）中，我們都有一個名為的子目錄/shared，類似于每個檔案夾的外觀，除了它只包含分類為的功能（例如) 域或資料。然后將這些東西在所有功能之間拆分。
例如，如果我有一個允許用戶發布內容的應用程式，我將post在功能內部創建物體（使用 ResoCoder 術語）/posts。除了，呃哦，我還需要在/feed功能中顯示它！/shared這是通用/domain目錄內部的完美案例。
讓我知道這是否有幫助，或者如果您有任何其他問題！
uj5u.com熱心網友回復：
干凈的架構是否允許跨多個功能共享模型和物體？
我認為無論你是否使用干凈的架構，都應該應用 DRY 原則。
至于答案：
我認為您可以將共享模型和物體抽象為單獨的模塊或包。如果都是 dart 代碼，我建議選擇包。您可以將它放在根專案（Monorepo）中或將其分離到另一個存盤庫，這樣您可以通過從主應用程式中抽象出所有共享依賴層（抽象類、介面、客戶端或存盤庫）來實作模塊化
在 Google I/O'19 上有一個關于這個主題的好視頻，它是關于 Android 的，但你可以獲得很好的洞察力并應用于一般的移動開發。我建議你試一試
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/509930.html
標籤：扑干净的架构