パッケージ図とマインドマップ

　私の本『ソースコードリーディングから学ぶ Javaの設計と実装』では、Javaのソースコードを読む際にはまず「ソースコードの地図」となるパッケージ図を描いて、そのパッケージ構造を把握してから読むことを薦めている。

　パッケージ図を使って依存関係まではっきり把握するのがベストなのだけれども、実際にやってみるとパッケージが膨大にあって描ききれない場合や、依存関係が複雑に入りくんでいて明確な構造を見出せないことが多い。その場合は、単にディレクトリの階層構造を表すような図を描くだけでもいいと説明している。


　上記のように素っ気なく描くのもいいのだが、パッケージ構成をマインドマップを使って描いてみるのはどうだろうか、と最近ふと思った。さっそく試しに、JRubyソースコードのパッケージ構成をマインドマップで描いてみた（ツールにはFreeMindを使った）。

　かなりいい。マインドマップは空間を上手に使うので、図に描き切れないパッケージを省略したりせずに、全パッケージを盛り込むことができる。プログラム全体がどんなサブシステムに分割されているのか、つまりプログラムがもつ主要な関心事は何なのかが、ひと目で分かるようになっている。ソフトウェアのソースコードを調べるときは、まずマインドマップを使ってパッケージ構成を調べてみる、というのはかなり使えるテクニックかもしれない。

　さて、ここでさらにもう一歩考えを進めてみる。マインドマップは、元々考えを整理したりするためのツールである。プログラムのパッケージ構成をマインドマップで描くことは、そのプログラムがもつ関心事を整理することにつながる。その効果を大事にして、逆に、先にプログラムの関心事をきれいに体系化したマインドマップをつくり、それを元にしてプログラムのパッケージ構成を設計してみるのはどうだろうか？

　最適なパッケージ構成を設計するのは、簡単なようでけっこう難しい。マインドマップ → パッケージという流れは、いいガイドラインになるのではないだろうか。その中で、従来のパッケージの分け方とは違う部分も出てくるかもしれない。しかし、マインドマップはドメインの知識を反映させるには、とてもいい場所になりそうだ。そんなマインドマップとソフトウェアのパッケージ構成とが緊密に関連付けられるとすれば、それはDDD（Domain-Driven Design）の思想を実践する1つの方法にもなると思う。