業務フローを通したいので、資源評価の状態遷移をはやくモデリングしないとと思いつつも、リファクタリングに時間を使ってしまった。 とはいえ内容は日本語でのモデリングで、自分としては初めての試みで勉強になった。 コードベースも、ドメインエキスパートにとっての読みやすさが劇的に改善したと思う。

以前、DDDの勉強会でお会いした方が日本語を使ってコーディングしていると言っていたので、日本語でDDDしている方々が一定数いること自体を知ってはいたが、その話を聞いた当時（3年ほど前だったと思う）には、入力モードの切り替えがめんどくさそうという理由で、正直かなりのマイナス感想（食わず嫌い）を持ったことを覚えている。その後も、モデリングに日本語を使いたいと思う機会は1ミリもなく過ごしてきたし、今回のこのリファクタリングも計画的したものではない。ふと試しに、ほんの数行だけ日本語を入れてみたところから始まった。日本語を入れるというのはもちろんただの文字列としてではなく、オブジェクトとして・型として書くという意味だ。

結果、事前にまったく想像しなかったレベルでメリットがあった。入力モードの切り替えは、静的解析に基づいた入力補完が利くのでまったく必要ないし、なにより読みやすい。表意文字は至高だ。ただ読みやすいだけではなく、日本語でやっている業務のことを表すのならばそのモデリングも日本語でやることが、実態とモデルの乖離を防ぐうえで最も効果的だ。

もう一つ、これは自分で実際にやってみるまでわからなかったが、母国語でモデリングすると、命名時の推敲の質が外国語でやる場合に比べて比較にならないほど高いことを実感した。これを経験してみると、自覚できないレベルのちょっとした命名・モデリングの歪みも、積み重なるとモデリングの歪みにつながり得ることが感覚的にわかった。命名は設計の構成要素（ビルディングブロックという意味で）なのである。

下記は、まだ英語で（というか以前の常識における「普通の」）モデリングしていた当時のSTOCK_GROUP_NAMESという定数のTypeDocドキュメント¹。アルファベットで書いてあると、ぱっと見では意味がとりにくい。

定数名自体を日本語にすると、ぐっと読みやすくなる²。

TypeScriptで下記のように書けるというのは本当に強力だ:

const hoge = 資源グループ呼称s.マイワシ  // "マイワシ"

また、過去の記事で、各資源に関する情報をまとめて保持しておくための定数（当時の名前はSTOCK_GROUPS）の構造を改善すべきと書いたが、現時点ではその問題も解消済みだし。こういう込み入ったオブジェクトは、日本語で書くと意味が取りやすくなる。表意文字は至高だ。

ただプログラミングに日本語を使っただけなのだが、明らかに新たな地平を見た。食わず嫌いは良くないと思った次第。