背景
基幹系系統遷移中，所謂的「複雜業務邏輯」需要被遷移。
最近因為讀了「開始學習領域驅動設計」，因此我會意識到使用該方法進行遷移。
詞彙的印象
有一個名詞叫做「複雜業務邏輯」，
我對此抱著「業務邏輯非常複雜」的印象。
但在此次遷移的系統中，實際上複雜的部分是那個「前處理」。
「對於輸入結果難以預測」的系統
此次遷移的對象，業務邏輯上是教科書式的簡單。
但是整體來看可預見性不佳，在運用中遇到了困難。
這就是所謂的「對於輸入結果難以預測」的系統。
此外，還與舊系統有聯繫，其中也描述了「值的加工」和「區分值的轉換」。
也就是說，處理被分散在多個層次中。
這使得整體的可預見性變差。
怎麼處理的
整理並重新構建一連串的處理過程非常艱難[^1]，
最終，確定了前述的「教科書式部分」和「前處理」的結構。
「教科書式部分」＝業務邏輯或領域邏輯
「前處理」＝模型轉換裝置或防腐層[^2]
是的。
（※最近因為讀了「開始學習領域驅動設計」，所以使用了那裡的術語）
閱讀困難的源泉
整理的過程雖然艱辛，但其成本相對應的成果是有的。
與業務邏輯相關的「值」所用的處理現在可以僅僅看「模型轉換裝置」。
以前為了理解與「值」相關的處理，需要遍歷整個系統方能掌握。
而現在只要看模型轉換裝置就可以了。
如是，之前的系統「可讀性差」的根本原因在於「相關處理的描述分散」。
心理抵抗
不過，過程中的變更並非易事。
為了避免描述的分散，需要徹底不在「模型轉換裝置」以外的地方加工數據。
不過，這項工作面臨了相當大的「心理抵抗」。
因為習慣了操作DB和SQL，因此「在數據附近去除空白和加工字串是更有效率」的感覺。
對於習慣做法的誘惑相當強烈。
從代碼量的角度來看
完成的系統，整體代碼量驚人地減少了。
但「業務邏輯」的代碼量卻比「模型轉換裝置」的代碼量還要多，這是個特徵。
這代碼量的差異似乎在告訴我們「在整理數據的部分存在複雜性」。
這是一種聽說過的模式，但實際看到的時候感覺格外違和。
畢竟最重要的「業務邏輯」卻寫得簡潔明瞭。
可以比喻為「做菜花了很長時間，但吃的瞬間就過去了」。
附註：「炒飯製作中，鍋具的最後烹飪僅需一瞬，而備料卻耗時較長」的例子或許更為合適。
[^1]: 詳情省略，但是依據「關注點分離」和「單一責任原則」等方法進行整理的。 ↩
[^2]: 模型轉換裝置（防腐層）是用來集中處理外部系統之間保持一致性的轉換處理的層。 ↩
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
