今天工作中遇到一個問題，在支付成功回調時支付系統中校驗金額報錯，需要在校驗金額時給定一個參數，做一下轉換，核心邏輯一共只有幾行，但是修改了半個多小時，主要時間花費在以下幾點。
首先是參數模型需要定義多套，系統的框架採用的是插件方式，如果涉及到比較定製的邏輯需要在各自的插件中完成，需要制定一個擴展點（接口中新增一個方法），定製擴展點的入參與返回值，這些定義都放在一個公共二方庫中，而系統的核心模塊中（領域模型）不依賴外部接口，因此需要進行依賴倒置，對於二方庫中定義好的模型需要在覈心模塊中重新實現一遍，而兩套模型的字段一摸一樣，如果後續需要修改模型，同樣兩個地方都需要修改一遍。DIP是一個典型的場景，DIP系統中內部模型不依賴外部模型，因此即使使用了外部模型，也會重新定義一套非常相似或者完全一樣的模型，目的是爲了自洽，屏蔽外部變化，但是在後面的變化中，往往兩套模型都是同步修改。除了DIP之外分層也會導致這個問題，之前同一個系統分了多個模塊，每個模塊都有自己的對外模型（接口，入參，返回值），結果就是同一個模型在不同層之間傳遞時層層複製，修改一個字段往往修改很多地方，對象的轉換更是眼花繚亂。
調用的不斷傳遞，一個接口獲取的數據，通過了多個接口的層層轉發，每個接口中都需要定義一套相似的方法，而接口中邏輯只是簡單的傳遞與轉換。
難以找到類的位置，當新增一個模型時，不是很方便就很定位到應該放到何處，同一個接口中不同方法的返回值被放到了不同的模塊中，被放置不同模塊的類之前差異並不明顯，導致需要徘徊類該放置到何處。
除了修改花費時間之外，由於依賴的二方庫較多（功能不一），導致打包部署也很繁瑣，讓人望而生畏。