昔、お客様の基幹系システムをスクラッチ開発していた頃、システム運用担当の皆様ともよく打ち合わせしたが、ビジネスルールを如何にわかりやすくコードに書くかではなく、業務上変わり得るルールならそもそもコードに書かず、ユーザー部門がテーブル登録する仕様にしてくれという話の方が普通だった。
この辺、この三十年ぐらいで、もしかしたらものすごく後退してきてるんじゃないかと感じることがある。
COBOL が Java になろうが、何かの関数型言語になろうが、変わり易いと分かっている業務ルールをハードコードして、リーダビリティ云々と言っているんじゃ、ソフトウェア設計としては、レベルが落ちているとしか言いようがない。
太陽電池でモーターを回し、木をこすって火を起こしている印象だ。
僕のいたのがコンサルティング会社でレベルが高かったー、みたいな話ではなくて、お客様の情報システム部門がまずそういうスタンスだったですね。
確かにやりすぎのリスクはある。普通のマスター項目以上、汎用言語未満、みたいなところで寸止めするのが結構大事。#やりすぎがちなアカウントの述懐
DBのカラムにJSのコード断片入れておいてごにょごにょさせる、みたいな。けっこう凶器じみているかも。
本件、メタプログラミングを志向してるんじゃないんです。変わると言われがちな要件の背後にある変わらぬものを見い出そうとする試みなんですね。まあ、メタプログラミングは本来そうだと言えば、そうかもしれない。
そりゃ昔（今も？）みたいにコードの変更は「まず稟議を上げて部門長の承認を得て、システム部門に申請してシステム部門の承認を得て、そこから開発企業に発注して、先方の対応を待って漸く実装されたら、受入試験を実施して...（略」みたいな状況だったら、そりゃ利用部門で柔軟に変更できるようなDSL的な何かが欲しくもなるだろうけど。
社内に開発チームを常駐させて緊急性・重要性の高い案件から処理していくアジャイル開発のスタイルを採用するなら過度な柔軟性はむしろ生産性を下げるのでドメインロジックはコードで表現するのがやはり最適解だろう。
とはいえ、DSL的な何かで処理やデータを自由に定義できるという方向性自体は間違いでも無いので、そういうのはダッシュボードツールやJupyter Notebook的なものを提供すればよいだろう。