ドメイン駆動設計

ドメイン駆動設計に関する良い資料があったのでメモ。
InfoQにログインすれば、概要をダウンロードできる。

【元ネタ】
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版

無料で読めるDomain Driven Designの概要

上記は「Domain-Driven Design: Tackling Complexity in the Heart of Software」に関する概要資料。
「はじめに: なぜドメイン駆動設計なのか」の節でなるほど、と思った。

マーチン・ファウラー の「エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)」によれば、オブジェクト指向による実装は本来、テーブルモジュールでもなく、トランザクションスクリプトでもなく、ドメインモデルにある。
つまり、OOAの本領は、ドメイン分析にある。

しかし、2000年代前半は、オブジェクト指向分析の花盛りだったが、実際の開発ではそれほどOOAを使わなかった。
何故なら、EJB、SOAなどのバズワードに侵されて、本来のオブジェクトを分析する風潮ではなかったから。

そして、今もオブジェクト指向分析は普及したとはいえ、日本ではそれほど認知されていないように思う。
RUPは確かに優れているのかもしれないが、日本では反復型開発というよりもウォーターフォール型開発の一つみたいだ。
あまりにもドキュメントが多すぎて、大型タンカーを操縦しているような雰囲気。

OOAに関する書籍は良い本がいくつかある。
「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)」をもう一度読み返してみて、図はUMLでないので分かりにくいけれど、モデリングの試行錯誤が分かりやすかった。

でも、OOAは要件定義以後の詳細設計や開発ではとてもスムーズだが、要件定義や業務分析ではあまり威力を発揮しないように経験上感じる。
UMLは詳細設計における分析ではピカイチだが、要件定義やビジネスモデルを描くプロセスでは、使いにくいし、本来のイメージを描ききれない。

OOAはAgile開発と密接に関係するし、アジャイラーは優れたモデラーもあった。
だが、要件定義や業務分析は、日本独自のDOAの方がいいのではないか、と思ったりもしている。

そんなことを思っていて、最近、OOAに懐疑的になっている。
要件定義や業務分析のプロセスでは、UMLやOOAが役立たない。
そして、アジャイル開発もうまく機能していない。
色々試行錯誤している。