背景
基幹システム移行でいわゆる「複雑な業務ロジック」を移行する場面です。
最近「ドメイン駆動設計をはじめよう」を読んだため、その手法を意識して移行を行います。
言葉のイメージ
「複雑な業務ロジック」という言葉がありますが
これは「業務ロジックが複雑」なイメージを持っていました
しかし今回移行したシステムで、実際に複雑なのはその「前処理」でした。
「入力に対する結果が予測しづらい」システム
今回の移行対象は、業務ロジックとしては教科書通りのシンプルなものでした。
しかし全体として見通しが悪く運用で苦労していました。
いわゆる「入力に対する結果が予測しづらい」システムです
また、レガシーシステムとの連携があり、そこでも「値の加工」「区分値の変換」が記述されていました。
つまり複数の層に処理が分散している状態です。
これが見通しの悪さにつながっていました。
どのように対処したか
一連の処理を整理して再構成するのは苦労しましたが1
最終的に、前述の「教科書的な部分」と「前処理」の構成に落ち着きました。
「教科書的な部分」＝業務ロジックまたはドメインロジック
「前処理」＝モデル変換装置または腐敗防止層2
ですね。
（※最近「ドメイン駆動設計をはじめよう」を読んだため、そちらの言葉をつかっています）
読みづらさの源泉
整理するのは苦労しましたが、そのコストに見合う成果はありました。
業務ロジックで使う「値」に関連する処理は「モデル変換装置だけ見ればよい」状況ができたのです。
以前は「値」に関連する処理を読み解くため、システム全体を渡り歩いて把握する必要がありました。
しかし今後は、モデル変換装置まで読めばよいのです。
このように以前のシステムが「読みづらい」のは「関連処理の記述が分散していた」ことに根本的な原因がありました。
心理的抵抗
しかし、その変更の過程は簡単でなかった点を補足します。
記述の分散を避けるため「モデル変換装置」以外ではデータを加工しないよう徹底する必要があります。
しかし、この作業は「心理的抵抗」が大きく苦労しました。
DBやSQLの扱いに慣れているので「データの近くで空白除去や文字列の加工すると効率が良い」という感覚です。
慣れたやり方への誘惑が強いですね。
コード量の観点から
出来上がったシステムは、全体のコード量も驚くほど削減されました。
しかし「業務ロジック」のコード量よりも「モデル変換装置」コード量の方が多いという結果だったのは特徴的でした。
このコード量の差が「データを整える部分に複雑がある」と語っているように感じました。
話には聞くパターンですが、実際に目にすると違和感がすごいです。
一番重要な「業務ロジック」のほうが簡潔に記述されているのですから。
例えるなら「料理を作るのは時間がかかかるのに、食べるのは一瞬」といった感覚でしょうか。
追記：「チャーハン作りで、プライパンで仕上げるのは一瞬で、仕込みのほうが時間がかかる様子」の例のほうが適切かも