いかにコードにドメイン知識を残すか

ドメインとは何か

ここ数年、ソフトウェアの開発手法として、ドメイン駆動設計（DDD）がホットなトピックと感じています。ドメインとはそもそも何かというと、実践DDD本 第2章「ドメイン」「サブドメイン」「境界づけられたコンテキスト」を読み解くの記事によると、「対象とする事業が取り扱う世界」を表すものとなっています。もちろんこの定義はすごく正確なのですが、個人な解釈としてはドメインとは「意味合い」というのがしっくりきています。「で、結局お前は何がやりたいの」という問いに対する回答がドメインであって、この回答を表現するためにモデリングを行う意義があると私は思います。

ドメイン知識とソースコード

さて、このドメインに関する知識をどう蓄積していけば良いのか。DDD ドメインモデリングサンプルの記事にある通り、モデル図や文章などを作成し知識を蓄積するというのが王道なやり方だとは思います。そのドキュメントをベースにソースコードを作成していけば、ドメイン知識とソースコードが結びつけられるので、ソースコードの意味合いが解釈しやすくなると思います。
ただ、一点感じるのはドメイン知識は、容易に失われるにある通り、コードとドキュメントの整合性を保ち続けるのは、かなりしんどいのではということです。そもそも、設計図通りにコードが書かれているという現場を私はあまり見たことないです。厳密に運用すればもちろん実現できないことはないと思いますが、やはり人間がやることなので、どこかでサボってしまうこともあると思います。

コードを正とするアプローチ

ドキュメントとコードの整合性を合わせ続けるのがしんどそうな場合、コードを正とするしかないと私は考えます。もちろんドキュメントを全く作らなくて良いというわけではないのですが、ドキュメントを見なくてもコードを読めば、ある程度意図が読み取れるような作りになっているのが望ましいと思います。
その点だとボトムアップドメイン駆動設計のアプローチは個人的には良いと考えています。ただ、実際にボトムアップでドメインを作り込んでいった場合、ドメインの全体像についてソースコードを追っていっても、見えにくいということもあると思います。

コードからドメインをどう読み取るか

ソースコードからドメインを読み取るにはどうすれば良いかということで、コード⇨モデルを表現する手段があれば、一つの解になるのではと私は考えました。逆に言えば、コード⇨モデルに表現できている状態であれば、そのソースコードにはドメイン知識が組み込まれているという事になると思います。
ドメイン知識を表現するにあたって、プロジェクトの全てのクラスを図示する必要はないと思ってます。重要なドメインに絞って図示化することで、小さく始めることが出来ると思いますし、既存のプロジェクトでリファクタリングした結果も見えてくるのではと感じます。

こんなの作ってみた

Javaのプロジェクトを対象に、重要なドメインのクラスにアノテーションを付与することで、PlantUMLのクラス図が出力できるツールを実験的に作ってみました。ツール自体はこちらに置いてあります。アノテーションを設定していくことで、こんなクラス図が生成されます。