實現類似的UseCases看起來像代碼複製

我有以下情況。用戶可以將多種對象類型（交易，發票等）導出到外部會計系統。導出算法具有以下步驟：實現類似的UseCases看起來像代碼複製

由一些濾波器取對象
出口對象逐一會計系統（每個對象類型的web服務方法）
寄存器，給定文檔導出的事實，所以它不會被導出再次
製備用於用戶概要（導出的文檔的NUM，錯誤消息等）

該算法爲所有對象類型相同，但有是必須處理一些重要的區別：

不同類型
不同的目標Web服務方法，不同的對象DTO映射
每個對象類型不同的過濾器

，我認爲是一個很少的解決方案：

不把輸出算法當成代碼重複並實現算法每個對象類型。任何外部系統中的任何數據的出口可能通過這樣的算法來描述 - 它意味着我們應該總是有任何出口到任何地方一類通用:)
移動差異策略（一個戰略界面來創建抽象的呢？所有的差異） - 我甚至實現了它。
使用泛型 - 不幸的是，我在編碼PHP和它不可能

問題：

是創建的每個對象單獨導出算法類型的代碼重複？

也許他們應該被視爲單獨的用例？

如果它是一個複製，然後避免什麼技術，這我應該考慮？

我的第一個執行說明：

在第一種方法中，我定義可導出的抽象，但我卻高興不起來了。每個對象有完全不同的有效載荷可導出的接口只定義了一個方法的getId並將其用於註冊該對象被出口（並且由於其不會被再次導出）。爲此，抽象是好的，但問題是轉移到exportService其中有檢查的具體情況來選擇DTO映射器和端點。所以exportService打破了SOLID。

來源

2015-06-24 Jakub Filipczyk

非常好的問題。您是否將用例之間的「包含」*和「擴展」*關係考慮在內？他們可能會在這裏幫助。另外一些模式，如* Framework *，* Extensibility *或* Template Method *可以替代您的實現方法。 – Waog

首先，您應該將過濾和導出視爲兩個不同的問題。您通常希望將差異移至策略，然後根據API設計的方式將策略選擇隱藏在Facade/Factory後面。例如，客戶端可能只執行'exportService.export（listOfExportable）'，但在內部基於'Exportable'的類型，將選擇一個Web服務端點以及一個dto彙編器。出口服務可以從外部進行配置，以避免違反開放原則。您也可以將策略選擇置於可導出 – plalx

使導出可指定策略的優點可讓您避免在導出服務中使用服務定位器模式。 exportService可以在'Exportable'上雙重發送以收集信息。同時，由於基礎設施問題可能在不應有的層面上泄漏，因此存在不利之處。這與「我應該將ORM註釋放在實體中還是應該使用外部XML文件？」類似。 – plalx

你有上述的事情都不是特定於域的邏輯（事實上，你甚至不提你的問題的問題域），所以我不認爲在領域驅動設計真的下降。因爲它不是特定於域的邏輯，所以我不會過分擔心代碼重複，特別是考慮到解決方案看起來不明顯。

保持簡單，分別寫出每個用例。如果你發現有很容易重構的通用代碼，那麼在讓所有的工作順利進行之後再做。在他們明顯需要之前，不要過度使用或添加模式。

來源

2015-06-24 13:22:01

它可能是他主域的子域。 *「註冊給定文檔已導出的事實，所以它不會被再次導出」*是域邏輯IMO。 – guillaume31

實現類似的UseCases看起來像代碼複製

回答

相關問題