<< テーブル設計 データモデリングのエッセンス(5) | main | Single is best. >>

Domain-Driven Design を Spring Framework で実践する

Domain Layer と他のレイヤ

Domain-Driven Design (DDD)では、一般的なアーキテクチャとして、次のレイヤ構造を説明している。
・User Interface
・Application Layer
・Domain Layer
・Infrastructure Layer
DDD では Domain Layer のオブジェクトの設計が、ソフトウェア開発の中核であり、開発プロセス全体を駆動するとしている。

では、他のレイヤの設計・開発は、具体的にどうなるのか?

ドメインオブジェクトと永続化

私たちは、永続化フレームワークとして、iBatis を使っている。 iBatis は、オブジェクト/リレーショナルマッピング ( O/R マッピング ) のツールで、SQL 文を XML ファイルに記述する方式。

ドメインオブジェクトの設計とテーブル設計は、ほぼ同時進行。というか、ドメインを分析することは共通。分析結果を Java で表現するか、データベースのテーブルで表現するかという違いなので、基本部分は同じ作業だと思っている。

ドメインオブジェクトとテーブルができてしまえば、iBatis を使った永続化メカニズムの実装はあっけないくらい簡単です。

クラスもテーブルも役割を単純にした設計をしておけば、永続化の SQL 文もシンプルになり、iBatis でのマッピング記述は簡単そのもの。

iBatis と Hibernate

永続化のフレームワークでは、Hibernate を使ったこともあります。Hibernateは、データベースアクセスが自動化され隠蔽されるのが、メリットでもあり、デメリットでもある。

iBatis のほうが、やりたいことを直感的に記述できるし、理解も容易、変更も簡単、というのが私たちの判断です。

ドメインオブジェクトとユーザインタフェース

ドメインオブジェクトとユーザインタフェースのマッピングは、私たちは、Spring MVC を利用しています。

Spring MVC は、View テクノロジーが選択可能です。私たちは、JSP ではなく、テンプレートエンジンの Velocity を使っています。

Spring MVC の Model オブジェクトを View にマッピングするメカニズムは、シンプルでわかりやすい。Modelオブジェクトは、ドメインオブジェクトをそのまま使います。

ユーザの入力内容の取得も、Spring MVC のデータバインドの仕組みを使って、ドメインオブジェクトに直接マッピングしています。 入力検証も Validater インタフェースを持った、ドメインオブジェクトを作って、Spring MVC の構成ファイル ( xml ファイル ) に記述するだけです。

ドメインオブジェクトさえ作れば、あとは、Spring MVC の xml ファイルと、Velocity のテンプレート記述ファイルを用意するだけで、ユーザインタフェース層は完成です。 追加のJava のプログラミングはありません。これこそ Domain-Driven (ドメイン駆動)の開発です。

ドメインオブジェクトとアプリケーション層

Eric Evans の説明では、アプリケーション層のオブジェクトは、業務処理の手順を管理することが役割です。

私たちは、このレイヤの実装に Spring Web Flow ( SWF )を利用しています。

Spring Web Flow は、画面遷移を、xml で記述して実装するフレームワークです。 MVC のC (コントローラ)のプログラミングが不要になります。

画面表示やHTTPリクエストの処理に必要なドメインオブジェクトを xml ファイルに記述するだけです。
ドメインオブジェクトの処理結果によって、別画面に分岐するなども含めた複雑な画面アプリケーションも簡単に実装できます。

ドメインオブジェクトと XML マッピング

Web サービス、REST 系のサービス、外部とのファイルでのデータ交換を実現する時、オブジェクトと XML 文書との双方向のマッピングが必要になります。 O/X マッピングですね。

このマッピングは、正式リリースされたばかりの Spring Web Services フレームワークを試行中です。ドメインオブジェクトの設計すれば、XML とのマッピングの面倒くさいプログラミングが不要になりそうです。

メッセージングサービスや電子メール

メッセージングサービスや電子メールも、Spring Framework を利用すると、低レベルのAPIを使ったプログラミングを簡略化できます。 ドメインオブジェクトが必要な情報持っているので、それを、メッセージとしてキューイングしたり、電子メールで送信する処理が簡単に実現できます。

DDD の実装基盤 Spring Framework

Domain-Driven Design で、開発を実践する場合、Spring Framework を中心に、iBatis, Velocity, Spring Web Flow ( SWF ) , Spring Web Services などをうまく使えば、他のレイヤの開発工数をずいぶんと減らせる。

開発者は、ドメインの分析と設計に集中でき、まさに Domain-Driven の開発になります。

フレームワークを習得して、使いこなすには、それなりの時間とエネルギーが必要ですが、それほど、高いハードルではないでしょう。永続化やユーザインタフェース部分での効果は絶大です。一度、使えるようになると、低レベルのAPIを駆使する開発に戻る気にはなれません。

フレームワークを使いこなすには、Domain-Driven Design をしっかりやって、疎結合で凝集度の高いドメインオブジェクト群をしっかりと用意することです。Spring 系のフレームワークは、そいういう良質の POJO を組み合わせるだけで、しっかりとしたアプリケーションを構築する便利な手段を提供してくれます。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
  12345
6789101112
13141516171819
20212223242526
27282930   
<< September 2020 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM