« 「プログラミングへのこだわり」を方向づける | トップページ | 「要件定義」に何週間もかける? »

2011.06.10

DDD:ドメインをメタ方向へずらす

 訳出が待たれていたエリック・エバンスの「ドメイン駆動設計(Domain-Driven Design、略してDDD)」の日本語版が出版された。私自身はオージス総研さんによる抄訳「DDD難民に捧げるDomain-Driven Designのエッセンス」を読んだだけで原著も訳書も読んでいないのだが、これを機会にDDDに対する私の考えをもう一度書いておきたい。これは前回記事「『プログラミングへのこだわり』を方向づける」で述べた主張を、視点を変えて再度説明したものでもある。

 domainという言葉には日本語の「問題領域」が当てられることが多いが、そもそも多義的というかいろいろな文脈で利用できる用語だ。数学では関数の「定義域」を意味し、これに近い用法が、DB設計において「日付」、「数量」、「金額」、「区分」等のデータ項目のカテゴリーを意味する使い方だ。その後、ネットワーク用語やソフトウエアの適用分野等の意味合いでも使われるようになったことはご存知だろう。

 DDDでは最後の「ソフトウエアの適用分野」の意味合いで使われているわけだが、このブログのテーマである「業務システム(基幹業務向けの社内事務処理支援システム)」もひとつの「ドメイン」を成す。ただし、同じ領域でより限定されたドメインを想定することも可能である。たとえば、業務システム全体をひとつのドメインとするのが次の1で、2、3とより「個別的」になる。3から2、1と上るのは「一般的」な方向だ。

1.一般業務システム

  個別的↓   ↑一般的

2.特定業種向け業務システム

  個別的↓   ↑一般的

3.特定事業所向け業務システム

 いずれをドメインと呼んでも用法としては間違いではないが、DDDの考え方を実際の開発に適用する場合、どの階層をターゲットドメインとするかによって手法の意義や有効性が大きく違ってくる。それがDDDに対する私の問題意識だ。

 感心できないのは「3.特定事業所向け」の階層をターゲットドメインとしてDDDを実践するやり方である。なぜならそれではスクラッチ開発(イチから組み立てる開発)をむざむざと繰り返すばかりだからだ。そして、保守担当者が交代してゆくことを前提とすべきであって、その過程でコードが「スパゲティ・ドメインモデル」とか「オレ様ドメインモデル」と化すことを抑止する決め手もないからだ。

 もちろん、OOPも会計知識もDB設計もバリバリであるような有能なプログラマが担当し続けることで、端的で保守しやすい圧倒的なコードが維持されるであろう。それはそれで素晴らしい。ただしこれは、場末のスナックでマイケルジャクソンが4、5人の酔客を相手に圧倒的な歌と踊りを披露して日銭を稼いでいるようなものだ。彼のパフォーマンスが光るほどに、タレントの使い方の残念さが際立つ。

 そんな残念さを是正するには、叩き台となるべき優良なレファレンスモデルが用意されていればよい。そういうものを開発するためのDDDプロジェクトを立ち上げるとしよう。そこでのターゲットドメインは「2.特定業種向け」の階層ということになろう。面白い仕事になるに違いない。

 ところがこれはDDDによって積極的に実践されているとは言いがたい。なぜならこれまで何度も愚痴ったように、DDDの原著が2003年に出版されてから何年もたつのに、記載されたモデリングパターンが盛り込まれた完結したレファレンスモデルがさっぱり流通していないからだ。その理由が何であれ「2.特定業種向け」のDDDが実践されないばかりに、「3.特定事業所向け」の実践に合理性がない。

 だからこそ私が期待するのは、「3.特定事業所向け」でも「2.特定業種向け」でもなく、「1.一般業務システム」をターゲットドメインとするDDDだ。「業務システム」の一般概念そのもののクラス構造を捉える。その際にDDDの知見が役立つはずだ。その階層でうまくやれたなら、完結したレファレンスモデルがないという情けない現状さえ是認されていい。

 では「1.一般業務システム」をターゲットにしてDDDがなされた場合、生み出されるソフトウエアはどんなものなのだろう。「3.特定事業所向け」をターゲットにすれば個別の業務システムが手に入る。「2.特定業種向け」をターゲットにすれば「個別の業務システムを手に入れるためのたたき台(レファレンスモデル)」が手に入る。「1.一般業務システム」をターゲットにしてDDDを実践することで手に入るソフトウエアはどんなものか。

 それは、個別の業務システムを生み出す「鋳型」のようなソフトウエアではないか。それは業務システムにおけるメタレベルのオブジェクト構造を保持していて、その上で個別仕様を様式にしたがって記述すれば、個別の業務システムが立ち上がる。それが「1.一般業務システム」のドメインモデルから生まれるソフトウエアなのだろうと私は考える。

 そんなモデルを構想したり実装したりすることは簡単ではないだろう。しかしプログラマにとって、個別システムの開発より100倍エキサイティングに違いない。また、個別システムを開発するためにいちいち有能なプログラマの手を煩わさずに済むようになるため、彼らが保守専任であり続けやすい状況をもたらす。思う存分ドメインモデルのリファクタリングに励めばよい。これは、マイケルがレコーディングスタジオや大規模ステージでの演奏活動に専任するのと同じレバレッジ効果をもたらす。

 私自身の経験を言えば、「1.一般業務システム」をターゲットドメインとして、業務システム開発用基盤OSS「XEAD Driver」を2年半かけて開発した。これを用いると、仕様書を書くだけでコンパイルもせずにシステムが出来上がる。仕様変更も仕様書を書き直すだけなので、「2.特定業種向け」や「3.特定事業所向け」の開発・保守が劇的に楽になった。こういうソフトウエアは実際に開発可能だし、もっと研究されていい。もし訳書が3年前に出ていれば、精読することでもっと効率的に開発できたかもしれない。

 そんなわけで、DDDはよりメタな領域をターゲットにして実践されるべきである。少なくとも、有能なプログラマを「3.特定事業所向け」の狭隘なドメインに引き留めつづけるための動機としては利用されてほしくないものだ。状況の進展をもたらすソフトウエアを生み出すために、プログラマが活躍する舞台をメタ方向へずらそう。DDDがその障害にならずに推進力になることを願う。

過去の参考記事:
個別案件にオブジェクト指向は要らない
「ドメイン駆動開発」への素朴な疑問

|

« 「プログラミングへのこだわり」を方向づける | トップページ | 「要件定義」に何週間もかける? »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: DDD:ドメインをメタ方向へずらす:

« 「プログラミングへのこだわり」を方向づける | トップページ | 「要件定義」に何週間もかける? »