ドメイン駆動設計とドキュメント

今更ながらドメイン駆動設計の本を読んだ。読みやすくはないが、確かにいい本だと思う。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

ソフトウエア開発は3つの要素から成り立っていると思う。

1. エンジニアリング: アルゴリズム、ライブラリ、インフラ等
2. プロセス: タスク管理、マネジメント、テスト等
3. モデリング: ビジネス要件をどうプログラムに変換するか

ここ20年くらいの日本の技術書としては1.は非常に多い。これは当然常に新しい技術が出てくるから。次に2.ではないかと。これはここ20年くらいのアジャイル開発手法への注目によるところが大きい。そして3.は重要にも関わらず、あまり書籍は多くなかったのではないかと思う。

この理由として、アジャイル開発ではドキュメントを軽視している点はあるのではないか。ウォーターフォール開発の問題として、膨大な設計書が挙げられる。設計書は"最初から正しい設計ができる"という思想の象徴であり、"最初から正しいことをあきらめる"というアジャイルからは忌避すべき存在と考えられている。

その結果、設計は個人に依存する職人芸になった。"ドキュメントはありません、コード読んでください"がむしろ誇るべきこととなった。

結果として新しくプロジェクトにアサインされた人が、まず膨大なコードのどこから見たらいいかもわからず途方に暮れる。各自がコードを読むための自分用のメモを作って…破棄される。この無駄なサイクルをどうにかできないかと常々思っていた。

全てをドキュメント化する必要はない。"重要なドメインにおけるモデル"が文書化されていればそれでいいのだ。

この本のいいところは、アジャイル開発時代における、ビジネス要件のモデリング手法において道しるべを示してくれる点だと思う。やるべきことは何か、全員で共有すべきことは何か、最低限ドキュメントを書いておいたほうがいいことは何か。重要事項と周辺事項の区別はどうすべきか。あきらめたほうがいいことは何か、その妥協策はどうすべきか。多方面にわたって記載されている。

また、ドメインエキスパート、ゲーム開発で言えばプランナーが、開発者とどう付き合えばいいかも教えてくれる。上記で言うとエンジニアリングはわからなくてもいいが、モデリングは開発者と話して認識を合わせたほうが良いということだ。

今は本を読んだだけで、実際に自分がどう適用できるかは未知数だが、いろいろ考えていきたいと思う。