ドメインドリブンデザインはDIやAOPなしでも十分な実装可能か？

ドメインドリブンデザイン（DDD）(source)はビジネスドメインコンセプトをソフトウェアにマッピングすることだ。これまでDDD実装法の中心はオブジェクト指向プログラミング（OOP）(source)だった。OOPではオブジェクトがビジネスドメインの実体を表し、そのドメインオブジェクトをプレインなJavaクラスやインターフェイスでデザインすることで、継承・カプセル化・ポリモーフィズムといったOOPの考え方を利用できる。

通常、ドメインオブジェクトはServices(サイト・英語)、Repositories(サイト・英語)、ファクトリなどの他のオブジェクトと協調する必要がある。またドメイン状態について変化の監視・キャッシングやトランザクション管理（再試行を含む）といった横断的な処理も行う。これらは再利用可能な非ドメインロジックで、通常ドメインレイヤも含めたコード全体にばら撒かれコピーされる。このロジックをドメインコードに埋め込むと非ドメインコードが混ざりドメインレイヤが乱雑になってしまう。

OOP単体ではドメインドリブンなデザイン/開発における非依存性（オブジェクトと横断的関心事（複数のオブジェクトに跨ったり共通したりする特性）間の密結合がないようにする）についての優れたデザイン方法が提供できない。ここで依存性注入（DI）(source)やアスペクト指向プログラミング（AOP）(source)が関わってくる。OOPを補完するこれらの考え方によって密結合を最小限に抑え、モジュール性を高め、より良く横断的関心事を管理できるようになるのだ。

最近ドメインドリブンデザインのユーザーフォーラム(source)でのあるスレッド(source)で議論されたのがこのことだった。この議論はRamnivas Ladda氏のプレゼンテーション(source)が元になっている。彼はそこでDDDはAOPやDIの助けなしに十分な実装はできないと主張し、AOPを使った適度な粒度のDIによってドメインオブジェクトが洗練された振る舞いを取り戻すという考えを示した。ドメインオブジェクトは豊富な振る舞いを提供できるよう、他の適度な粒度のオブジェクトにアクセスする必要があり、それはサービスやファクトリやレポジトリをドメインオブジェクトに注入することで行える（アスペクト機構を利用してコンストラクタ(source)やセッターメソッド(source)の呼び出し時点で依存性を注入する）と説明した。

ドメインオブジェクト間の依存性（例えばエンティティとレポジトリ間の依存性）をうまく管理することは、DDD開発者がよく突き当たる古典的な問題だ。この問題に対しての通常の策は、サービスあるいはファサードクラスにレポジトリを直接呼び出させ、レポジトリでは呼ばれた時にエンティティオブジェクトをクライアントに返すというものだ。しかしこの方法はファットなサービスレイヤと貧血症ドメインモデル(source)を作ってしまう。ファサードクラスはどんどんビジネスロジックを持つようになり、ドメインオブジェクトはゲッター/セッターメソッドを持った単なるデータの運び役になる。

InfoQはドメインドリブンデザインの本(source)を執筆したEric Evans氏(source)と上記のRamnivas Laddad氏(source)に、DDDの実装におけるDIとAOPの役割について聞いた。DDDはAOPやDIなしで実装できないと言ったことについてReminivas Laddad氏に尋ねると、その前段階はドメインオブジェクトがもっと洗練され、レポジトリやサービスといった他のオブジェクトと協調しないといけないのかどうかという話だったと語った。

これはドメインオブジェクトが他のオブジェクトをどうやって取得するかという問題です。DIはそれにふさわしい方法に思えます。またこの時にAOPが関わってきます。Springがどのように生成されたオブジェクトでもDIできる（application context(source))内で宣言されたオブジェクトに限る）のと同じ方法ができるようにするのです。もちろんAOPはどんなドメインレベルの横断的関心事に対して有効です（ドメインコンセプトがソフトウェアに可能なかぎり厳密にマッピングされていることが前提となる）。

Eric Evans氏はOOP、DI、AOPという考え方をどのようにDDDの実装にフィットさせるかを語ってくれた。

DDDはモデルコンセプトの抽象化と表現ができるどんなパラダイムでも行えるのですが、実際にはほとんどがOOPで行われています。なので、OOPがDDD実践の基盤となってきました。

最近になってDIはとても広く行われるテクニックとなり、それを上手く行えばDDD実践者がデザインを改善する手助けになっています。私からみて一番重要なのは、DIがドメインの分離において役立つということです。

AOP のポテンシャルは認識され始めたばかりです。AOPにはドメインレイヤをまとめる力があるように思います。これはモデルコンセプトを明確に表現するのに役立ちますし、おそらく分離にも役立つでしょう。ただ、OOPやDIと違ってまだ実践された真の”基盤”とはなっていません。

この３つがDDDを支援する現段階でのベストプラクティスなアーキテクチャの基盤となります。

彼はDDDのフィロソフィとそれを実現するさせることを助ける技術的なツールボックス（OOP、DI、そしておそらくAOP）との線引きを明確にすることが重要だということも強調した。

横断的関心事やDIを定義したり管理する方法としてアノテーションを使うのが最近のトレンドだ。Springでは@Configurable(source)をレポジトリやサービスをドメインオブジェクトに注入するのに用いる。InfoQはEric Evans氏にDDDプロジェクトでのアノテーションの役割について尋ねた。

一般的には、アノテーションのようにドメインコンセプトを表すオブジェクトに付加されるものは、そのオブジェクトに対して概念的に意味のある何かを伝えます。@Configurableは処理について宣言するもので、ドメインについてではありません。そのためこのようなアノテーションがドメインオブジェクトに付くのは好みません。私の場合、レポジトリにインターフェイスおよび実装を作りますが、インターフェイスはドメインの分野のものと考え、実際に使えるレベルを維持しながらなるべくクリーンで概念的なレベルに留めるようにします。しかし実装はたいていいつも個々の技術を用いることになります（典型的な例としてはDAO）。@Configurableはレポジトリについての実装で使います。これは理にかなったことだと思います。

Spring フレームワークではこの”ドメインオブジェクトDI”の考えを@Configurableアノテーションより進んだ方法で持つようになる。 Reminivas Laddad氏はSpringの次期バージョン2.2.5での改善点（build 379のスナップショット(source)）から利用可能になっている）について最近ブログ記事(source)を書いた。このバージョンではAnnotationBeanConfigurerAspect,、 AbstractInterfaceDrivenDependencyInjectionAspect、 AbstractDependencyInjectionAspectが加えられ、これによりドメインオブジェクトのDIをより柔軟かつシンプルに行えるようになっている。２つ目のアスペクト（AbstractInterfaceDrivenDependencyInjectionAspect）が取り入れられた主な理由として、彼はドメイン独自のアノテーションとインターフェイスが使えるようにするためだと述べている。彼はまた @Configurableはシンプルだが最も洗練された選択肢とはいえないだろうとも述べている。

ビジネスサービスのオーケストレーション（ある処理を行うために必要なサービス間の複合的相互作用を管理する）やドメインオブジェクトのライフサイクルについても議論がある。BPEL（Business Process Execution Language：ビジネスプロセスモデリング言語のひとつ）がどれくらいドメインオブジェクトのライフサイクルと異なるドメインオブジェクト間のやり取りについて影響を及ぼしたか、という問いについてEric Evans氏は以下のように答えた。:

オーケストレーションとライフサイクルの関係については用心しないといけません。オーケストレーションは、パーツを分離する方法としては優れているでしょうし、ワークフローを何らかの形で表現すれば協調させることができる点でも優れているでしょう。一方、ドメインエンティティのライフサイクルがモデルにおいて中枢的意味を持つ場合、その責任をオーケストレーションに任せれば結果としてドメインオブジェクトは骨抜きにされ貧血症ドメインモデルになるでしょう。このことについての模範解答はありません。これは良いモデラ/デザイナによってケースバイケースで評価することです。