以前noteに書いた記事ですが、管理上こちらにも転載。
なるべくドメインを表現したコードにしよう、というのはそりゃそうなんだけど、ちょっとした記述方法だけでもドメインが持っていた意図は容易に失われる(だからこそどうやって表現を残すか考えないといけない)っていう趣旨のエントリでした。
ドメインにはドメインの都合があるし、コードにはコードの都合があるんだよね。完全にどちらかに寄るわけじゃないけど、後世の人にとって都合の悪い寄り方はあると思う。
例えば区分コードみたいな値が有ったとして、1の時は○○という処理、2,3,4の時は△△という処理を実装する、という状況のときに、条件分岐が「区分コードが1か、それ以外」で分岐させると、2,3,4と限定しておきたかった、というドメイン知識が失われたりしませんか?みたいなことが有ったり無かったり
— magnoliak🍧 (@magnolia_k_) 2020年7月3日
以前、暗黙知のスライド書いたときにも取り上げたけど、「年齢計算ニ関スル法律」には2月29日生まれのことは何も書かれていないけど、「前日の夜12時に一つ年を取る」というビジネスルールなので、”結果的に”2月29日生まれに例外ルール無しに対応できているんだけど、それは結果論なんだよ
— magnoliak🍧 (@magnolia_k_) 2020年7月3日
さんざん検討して、シンプルなルールで、複雑なパターンや例外パターンに”結果的に”対応できているって事例はおそらくたくさん有ると思うんだけど、その”対応できている”という事実は容易に失われるんだよなぁ
— magnoliak🍧 (@magnolia_k_) 2020年7月3日
コードがドメイン知識を表現するように書かれるべき、という話と、全体を疎結合にして拡張性や保守性を担保しましょう、という話、完全には両立はしないと思っていて、だってビジネス側の人はそんな拡張性とか保守性の話していなくね?
で、実際のコードを見たら、考えたこともない保守性や拡張性のための抽象化が行われていて、上から読んでもよく分からん、みたいなこと、発生していない?
そうでなくても冒頭の、ちょっとしたコードの書き方でも、元々考えていたドメイン知識からの要求って失われたりしませんか?って
区分コードに5が追加された時、全然違うところにとってつけたような分岐が現れてしまうこと、ありませんか?
コードの改修のしやすさと、ビジネス側からの要求が一致していないとき、後世の人は、先人たちの考えたことが分からなくなってしまうのです。