ひがやすを技術ブログ

電通国際情報サービスのプログラマ

ダイコン時代の設計手法 - クラス図なんて要らない

ほぼ、クラス図不要論とおなじなのですが、自分の意見を書いておきます。
ドメインをデータと振る舞いの点から考えてみたいと思います。


データはどのように永続化するのかが最も重要です。
RDBMSを使う限りはRDBMSに適したようにモデリングしたほうがいい。
HibernateなどのORMを使えば、RDBMSを使っても理想的なドメインモデルを
構築できると主張する方もいるかもしれません。
すべてのプロジェクトの参加者がオブジェクトを通じてデータを見ているなら
それでも良いと思います。
しかし、実際はテーブルに入っているデータで結果を確認しているのが
ほとんどではないでしょうか。
特にユーザはオブジェクトなんて興味はありません。
データの入出力もテーブルを通じておこない、テスト結果の確認も
テーブルを使います。
JavaRDBMSで違うモデルを構築してしまうと開発者は相互に変換を
行わなければならず負担が大きくなります。
仮に、コーディングの面はORMが自動でやってくれるとしても、
モデルを脳内で交互に変換するのは開発者にとって大きな負担です。


振る舞いの点からも考えてみます。
古典的なオブジェクト指向ではデータと振る舞いをカプセル化して扱ってきました。
データと振る舞いの安定度が同じな場合は、そのほうが良いと思います。
しかし、ビジネスプロセスにおいては、データは比較的安定しているのに
対し、振る舞いは仕様変更や仕様追加が入ったりして、最後まで安定しません。
このような場合に、データと振る舞いを一緒にしてしまうと、ある業務に
無関係な業務が追加されたりした場合にでも、クラスに変更が入り、
テストをやり直す必要が出てくるようなケースも発生します。
変更に対する影響をできるだけ少なくするためのオブジェクト指向だったはずなのに
逆に変更の影響範囲を広くしてしまうケースもあるのです。
このようなことを避けるため、ダイコン時代のオブジェクト指向では、
振る舞いは最も結びつきの強いクラスに置くことを推奨しています。
そうすると振る舞いは業務ロジックを表すクラスにおかれることになります。


こう考えていくと、クラス図なんて必要ないじゃんと思ってしまうわけです。
データのモデリングRDBMSに最も適したER分析が向いていると。