DDD 読書会 #3(前半)

DDD読書会の日記だったはずですが、すっかり解説になっていますね…。まあ、それはともかく。

4章 Isolating the Domain

前回も触れた通り、 Part 2 は良く知られた実装のパターンが紹介されています。

最初の章である4章では、アプリケーション全体の構成に関わる二つのパターンが紹介されています。一つは今回紹介するレイヤー化アーキテクチャです。もう一つの、スマートUI「アンチパターン」の紹介は次回になります。

なお、今回のレイヤー化アーキテクチャや、その他のパターンを使ったプログラムのサンプルが公開されています。実装のイメージのつきにくい人は参考にすると良いかもしれません。

Layered Architecture (レイヤー化アーキテクチャ)

レイヤー化アーキテクチャで言うレイヤーとは、以下の4層になります。プログラムを4つの役割に分離し、下の層からは上の層を使わないように(または「見えない」ように)します。

  • UI層(プレゼンテーション層): 表示と入力の解釈を行う。XMLのサービスなど、別のシステムとのインタフェースもこの層に含まれる。
  • アプリケーション層: UIとドメインの間で調整をする薄い層
  • ドメイン層(モデル層、ロジック層): ソフトウェアのドメインに関する処理を扱うメインの層
  • インフラ層: 技術的な詳細を吸収する層、ライブラリや汎用ロジック


このように分離する理由を一言で言えばメンテナンスをしやすくするためなのですが、いくつかの面があります。


一つは粗結合性です。ドメイン層はUIやアプリケーションの層に依存しないので、例えばUIの拡張や変更にも少ないコード変更で対応できます。ユニットテストも行いやすくなります。

同時に、処理を明確に分離する事でコードのまとまりが良くなり(凝集性が上がり)ます。凝集性が上がるとコードが分かりやすくなり、またコードの修正時に色々な場所を変更しなくて済むようになります。レイヤー分離によって凝集性が上がるかは実際の所は状況次第だとは思いますが、アプリケーションが複雑であるほど効果は上がるのではないでしょうか。

最後に、ドメイン層の分離はドメイン駆動設計には必須とされています。ドメインモデルはドメイン層に記述することになるからです。

感想

この章を読んだ時、色々疑問点や思う所があったので、それについて書いてみます。

MVCとの関係

アプリケーションの有名かつ古典的なアーキテクチャMVC というのがあります。コントローラー(C)が入力を解釈、モデル(M)を操作して、その後モデルをビュー(V)が表示する、というものです。この MVC は、今回のレイヤー構造のどこに対応するのでしょうか?

基本的には、モデルがドメイン層、ビューとコントローラーがUI層になります。MVC で最も重要な考えはモデルをそれ以外と分離する事です*1。この考えはそのままレイヤーアーキテクチャに継承されています。

アプリケーション層について

それでは、アプリケーション層はMVCのどこに対応するのでしょうか?

これは、個人的にはこの層は MVC にはあまり明確に説明されていなかった概念に思えます。ドメインとUIの調整を行う場所はケースバイケースです。それほど複雑でなければ実際はコントローラーに入れてしまうこともあるでしょう。調整が複雑であればモデルと称してコントローラーとは分離して実装されているかも知れません。

実際の所、本書でもアプリケーション層とUI層の境界は割と曖昧に扱われているように思います。ドメイン駆動設計の立場としては、ドメインと他の境界が明確になっていることが重要で、後は本書の範囲外ということなのかもしれません。

ちなみに、MVCやアプリケーション層のバリエーションに関しては、マーチン・ファーウラーのページが詳しいと思います。

http://martinfowler.com/eaaDev/uiArchs.html


次回は、スマートUI「アンチパターン」を紹介します。

*1:昔のMVCにある、オブザーバーパターンを使ってモデルとビューを同期するという考えは、最近(特にWebで)は伝えられていないことがあるので、ここでは触れないことにしています^^;