「データベース実践活用」の連載をはじめました

本日発売のWEB+DB PRESS Vol.81からデータベース実践活用という記事の連載をはじめました。次回と次々回まで自分が担当する予定です。

WEB+DB PRESS Vol.81

第一回目は、オブジェクト指向プログラミングを利用したDAO設計パターンの紹介です。DAOってあれですね、データアクセスオブジェクトです。RDBとかKVSとかファイルとかごにょごにょするオブジェクト群のことですね。

最近は、ORMとかいろいろ便利なライブラリが整備されてはきてるんですが、実際にはDAOの実装にはいろいろなパターンがあって、作るシステムの要件によって最適な実装というのは異なってきます。特に最近は、扱うデータストアがRDBだけじゃないってこともあってより、複雑なDAOの設計が求められています。

今回の記事の内容は、エンジニアが担当ソフトウェアアーキテクトになってWEBシステムを作る際、データストアの構成、ドライバの選定、ORMの選定までは済んだけれども、ソフトウェアの設計をどのようにしようかと悩んだ時に役に立てばいいな、という内容になっています。

今回紹介しているパターンは以下の表の通り。

パターン名	概要	用途	保守／拡張性能	実装コスト
トランザクションスクリプト	データベースに対する一連の手続きをタスクとしてオブジェクト化する手法。共通ロジックに関してはサブタスクにすることもある	長期保守しない、パフォーマンスが求められるシステムの実装	とても低い	とても低い
テーブルゲートウェイ	データベースのテーブルに対しての処理のゲートウェイとなるオブジェクトを用意する手法	短期間の保守を行い、複数のテーブルをまたぐような複雑なビジネスロジックが存在しないシステムの実装	低い	低いがテーブル間の関連が多いビジネスロジックの場合は高い
アクティブレコード	データベースのテーブルが持つ特定の行をラップする手法。オブジェクトはデータと振る舞いの両方の特性を持つ	データベースの構造とビジネスロジックに乖離(かいり)が少ないシステムの実装。または、要求変化が少ないプロトタイプの実装	中程度だが単純なビジネスロジックの場合は高い	中程度
データマッパ	永続化対象、データベース、マッパ自体がそれぞれ独立したオブジェクトとなっている構造を持つ	中長期の保守が求められ、複数のデータベースおよびテーブルより1つのオブジェクトを構成するようなある程度複雑なビジネスロジックを扱うことのあるシステムの実装	高い	高い
ドメイン駆動設計におけるリポジトリ	データマッパの抽象度をさらに高め、扱う永続化対象オブジェクトとビジネスロジックで扱うオブジェクトを分離する方法。また実際の永続化方法についてはビジネスロジックからの隠蔽(いんぺい)を行う	長期保守が求められ、ビジネスロジックのデータベースへの依存を断ち切りビジネスロジックが凝集されたモジュールを構成しなくては保守が難しくなるような、とても複雑なビジネスロジックを扱うシステムの実装	とても高い	とても高い

特に、アクティブレコードパターンと、データマッパーパターン、ドメイン駆動設計(DDD)のリポジトリあたりは実際にどれを採用するか、WEBシステムのアーキテクチャなら一度は頭を悩ませたことがあるのではないかと思います。

実際にはどの方法にも良し悪しがあるので、これが一番！ということはできませんが、クラス図と共に細かく説明していますのでご一読頂ければ適切な判断ができるようになるのではと思います。

またDDDのリポジトリのは特に実際どのようにすべきかということで悩まれている方もいらっしゃるかもしれません。なので今回は具体的な実装を十分に用意してみました。番組と番組タグという情報を例に取ったScalaの実装例を sifue/oopdb · GitHub および サポートページ：WEB+DB PRESS Vol.81：｜gihyo.jp … 技術評論社 にて公開しております。sbtでビルドして動かすこともできるので気になる方はこちらの方をみてどのような構成になっているのか見てみてください。

追伸
実はサンプルコードを最初はJavaで書いてくれと言われたのですが、PoEAAやエリック・エヴァンスのDDD本にもJavaのサンプルコードは沢山あるし、Scalaの方が短くかけて構造が簡潔に伝わりやすいと思い、Scalaを選択しました。型があるのに短くかけるScala、いいですね。