またまたドメインオブジェクト

以下に、僕の理解する所のドメインオブジェクトについて記します。間違ってたり、違うと思うところがあったら指摘してください。

Wikipediaによると、ビジネス・オブジェクト(ドメインオブジェクト)とは以下のような定義だそうです。

Business objects are objects in an object-oriented computer program that represent the entities in the business domain that the program is designed to support. For example, an order entry program might have business objects to represent each orders, line items, and invoices.

Business objects are sometimes called domain objects; a domain model represents the set of domain objects and the relationships between them.

一般的に、ドメインオブジェクトとかドメインドリブンデザインというと、ビジネス、業務のエリアの設計・デザインを指します。しかし、ドメインという言葉自体は『領域』という程度の意味合いなので、ドメイン・オブジェクトが発注とか受注といった業務アプリケーションにしか存在しないというのは間違いだと思います。例えば、デバイスドライバーをオブジェクト指向的に書いたら、『割り込み』とかはデバイスドライバーというドメインにおけるドメインオブジェクトになるでしょう。

また、DSL(ドメイン・スペシフィック・ランゲージ)という言葉のドメインという言葉の使いかたは、正に、単に領域という意味で使っています。例えば、AntはビルドというドメインにおけるDSLだし、Railsはウェブアプリケーション開発というドメインでのDSLです。でもAntもRailsもビジネス・アプリケーションではありません。Antはビルドのツールだし、Railsはウェブアプリケーション開発のためのフレームワークです(その上で作ったものはビジネスアプリケーションになる場合が多いですが)、

Osawatさんからコメントされた、XXXManagerとかはドメイン・オブジェクトなんだろうか、ということについてですが、それはXXXManagerオブジェクトの持つ責任／役割によると思います。それが、開発対象のドメインに属する処理、例えば在庫の引き当てとかだったら当然ドメイン・オブジェクトになるでしょう。

ここで注意しなければならないのは、従来の多くのJ2EEのアプリケーションの設計はデーターベースドリブンだったということです。本来のOOPでいうオブジェクトは、データとそれに対する処理が一体化したものです。しかし、多くのJ2EEアプリケーションは、データーベースのレコードを保持するエンティティ・オブジェクトと、処理のロジックだけを持つオブジェクトに分かれていました。悪名高いEJB2のエンティティ・オブジェクトと、それを回避するためにデザインパターンとして、こういうのが推奨されてきたわけですが。

Domain Driven Designが言っているのは、本来のOOPのデザインをしようということだと思います。つまり、『受注オブジェクト』といったら『受注数みたいなデータ』と受注関係の『ロジック』も、受注オブジェクトに持たせようということです。また、ある一つのオブジェクトの処理として実装すると不自然になる処理、２つのオブジェクトにまたがる処理、例えば、受注数の更新と在庫の引き当ては、一連の処理として行いたい場合、この処理はどこに属するべきでしょう。多分、受注オブジェクトでもなく在庫オブジェクトでもない、XXマネージャーとかXXサービスとかに含めたほうが、自然だと思います。でも、このXXマネージャーはあくまでも、そのドメインの処理をしてるのでドメイン・オブジェクトです。

追記
佐藤 匡剛さんのBLOGと
Java EE勉強会のページが大変参考になりました。