プロダクト初期からリリースまで、ドメイン駆動設計でプロダクトを設計していけば、頻繁にモデルの名前を変更していくでしょうし、チームで議論する機会も多いかと。
これが、プロダクトがうまく行って、運用も安定していくと、モデルの名前が変更される機会が減ってきていないでしょうか？
しかし、プロダクト初期に付けた名前や最初につけた名前がずっと正しいとは限りません。
まずはその理由を探ります。
最初に付けた名前が正しいとは限らない
1. 実装時には違和感に気が付かないことがある
実装している人やチームは当然そのモデルの名前をつけた背景やロジックを知っているわけで、それ故、違和感を感じるべき名前でもそのときには気が付かないことが多いです。 後からチームに入ってきた人が見ると、なんでこの名前なんだろう？？？と思うわけです。
2. 外部連携先に名前を合わせがち
本来、外部連携先というのはコンテキストの外なので、名前を合わせる必要はありません。むしろ、自分のコンテキスト内での業務内容から名前は決められるべきで、外部連携先での名前をそのまま使うと意味がわからなくなることもあります。
3. 比較対象のあるモデルがあったから違和感がなかった名前
例えば、Light○○という名前や、○○Detailという名前など、相対するHeavy○○や○○Summaryがあってはじめて成立するような名前が付けられがちです。 当初は一緒に実装するので違和感がありませんが、その名前単体で見るとなぜその名前が付けられたのかわからなくなることがあります。 特に、相対するクラスを使わなくなった場合や、比較対象のクラスが3種も4種もあったりする場合などは要注意です。
4. チームのメンバーが減る、または作業が分担されてモデルについての議論が減る
プロダクトが安定してくると当然作る機会が減るわけで、チームのメンバーが減ります。また、アーキテクチャの構築なども安定しているため、チームみんなで考えるより、メンバーがそれぞれ分担して作業をする方が早いと考えられて一人で名前を考えて、そのまま名前が決まってしまうことが増えがちです。 当初はユビキタス言語を意識してみんなで決めてた名前も、段々と実装者とレビュー者ぐらいしか名前を決める人がいなくなることも。 そのレビュー者もプルリクを確認する程度で対面ではなく、画面ごしの議論ぐらいしかしなくなり、多少違和感がある名前でもレビューを通してしまうなんてことも多いのではないでしょうか？
一人で決めた名前というのは意外と通じにくいものです。自分では違和感ないと思っていても、他人が見ればおかしいと思うこともあります。 個人のベースであったり知識量であったりでそういうので差が出てしまうもの。
また、世界ではじめて「猫」を「猫」と名付けた人は、周りの人にも「猫」は「猫」だと伝え、かつ納得されなければ、「猫」が「猫」という名前になり得なかったわけで、一人で名前を決めるというのはとても難しいものなのだと思います。
5. 業務の概念が増えて、わかりずらくなる名前がある
当初は単純な業務でモデルの名前にも何の違和感もなかったクラスも、プロダクトが発展して、新しい概念が入ってきてモデルが増えると、単純でわかりやすかったクラスがぼんやりわかりづらくなることがあります。 似たような概念が入ってきた場合や、業務が変わり新しいモデルを作ったのに元のモデルも残っていたり（移行期などでそのままにしていたけど、ずっとそのまま動き続けていることも・・・）する場合などがあります。
概念はそのままで、後から場合分けが必要なケースが出てくる場合もありますよね。
例えば、「代引き手数料」という概念しかなかったので「手数料」という名前にしていたら、「即配手数料」が出てきた。 その時、「手数料」という名前はそのままで「即配手数料」を追加した。 あとから「手数料」を見ると、何の手数料かわからなくなりますよね。
安定した運用フェーズに入ったといっても、新しい機能も追加されずそのまま保守だけ続いているなんてプロダクトは少ないでしょう。 常にプロダクトの周りの状況、顧客の状況、社会の状況、自社の状況は変わっていて、それらに追随して常に新しいサービスを追加すべくソースコードに手が入るはずです。
そのような状況でモデルの名前も初期リリース後、全く変わらない状況というのは、実はそれは危ない兆候ではないでしょうか。
そこでこんな状況は危ない！という例を挙げてみます。
危ない兆候を見出すシグナル
1. モデルが変更されていない
そもそもモデルが変更されていない、ということに気がつけばベストなのですが、これがなかなか気が付かない。
技術的負債を解消したいとか、リファクタリングをしたいというケースは多重ループを減らすとか、不要なelse句を無くすとかロジックの読みやすさを重視したものが多いのではないでしょうか？
なので、モデルが最近変更されてないなぁなどと気がつくことは意外と難しいことなのではないでしょうか？ そこで他のシグナルを探ってみます。
2. いつもハンドラーやコントローラーからソースを追っている
他の人に説明する際や、変更や新規サービス追加時に周辺のソースを読むことから始めると思いますが、常にハンドラーとかコントローラーから、ロジックの最初から順にソースを追っていませんか？
周辺のモデルやクラス図から業務を追うことができなくなったとき、こういう傾向になりがちです。
そういう状況になる原因として、モデルの名前が不適切でわかりずらくなったとか、パッケージやコンテキストにクラスが増えすぎてわかりづらくなったとかそういうことがあるはずです。
3. コメントに残しとけ発言が増える
モデルの名前の意味がよくわからないとき、そのクラスの役割や背景についてコメントを残してしまうということが増えます。
コメントはいくら書いても動きに関係ないので、名前を変えるより一見リスクが低いような気がします。それ故こういうことが起こる。
しかし、コメントは動きに関係ないので、メンテされづらいという側面を忘れてはいけません。
名前がおかしいなら名前を変えましょう。
4. チームが集まる機会が減った
運用が安定し、チームのメンバーが減ったり、分担してタスクをこなすようになってしまったりでチームで集まる機会が減ってくると当然、名前に関する議論も減るわけで、よい名前がつけられていないことも大いに有り得ると思います。
気がついても直したくないという意識が働いてしまう
このようなシグナルに気がついても、どうしても直したくないという気持ちが働いてしまうものです。 なぜならモデルの名前は静的、つまり変更しても、しなくても動きに影響がない上に、ロジックの読みやすさ自体にも影響がないものです。 だから一度決めた名前を変更しようという意識は働きづらい。
しかし、モデルの名前というのは読みやすさだけがその目的ではありません。
モデルの名前変だけど、直したくないなぁと思ったら、もう一度、ドメイン駆動設計本の 第一部第一章(知識をかみ砕く)と二章(コミニュケーションと言語の使い方) を読むことをおすすめします。
安定したフェーズに入ってこそ、モデルを見直してみませんか？という提案の記事でした。