http://www.martinfowler.com/bliki/ReportingDatabase.html

ドメインモデルを使っているとき、アドホックなSQLへの対応はどうすればよいか？’’’

ドメインモデルの利点として、アプリケーション内のデータに重要な振る舞いを与えるという点が挙げられる。データのレポートが欲しいのであれば、ドメインモデルは非常に便利である。しかし、多くのレポーティングツールはSQL対応のデータベースを前提としている。つまり、ドメインモデルには対応していないのだ。では、ドメインモデルが出来ることは何だろう？

最初にやらなければならないのは、アドホックなレポートの必要性を問うことだ。アドホックなレポートが多すぎるというのは、誰もその必要性をちゃんと確認していないというだけのことである。 本当に必要かどうかをチェックすれば、アドホックなレポートがどれだけ「不自然なもの」かが分かるだろう。それから、ドメインモデルに対してコーディングを行うことで、アドホックなレポートに十分対応できるということにも気付くはずだ。 レポートは素早く作成されることが必要なのであり、ユーザーはいかに作られるかなど気にしていない（どうせSQLを自分で入力したいとも思っていないだろう）。

これは、すべてのケースにあてはまるわけではない。たまに、SQLベースのレポーティングツールが好きで、直接使いたいと思っているようなパワーユーザーがいる。そういった場合のうまいやり方は、レポーティングデータベースを構築することだ。レポ—ティングデータベースは実際に運用しているデータベースとは別のデータベースである。 レポ—ティングデータベースでは、ドメインモデルに対して行ったコードが走っている。なので、ドメインモデルから生成されたデータをレポーティングデータベースに入れることができる。これにはいくつかのメリットがある。

  • ドメインモデルを経由しているため、ドメインモデル内でデータを生成してから、レポーティングデータベースにデータを入れることが出来る。
  • レポーティングデータベースはリードオンリーなので、最適化する必要がない。
  • レポーティングデータベースの構造は、レポートをいかに簡単に作れるかにフォーカスを当てて設計することができる。
  • 開発者はレポーティングデータベースに影響を与えることなく、運用しているデータベースをリファクタリングすることができる。
  • レポーティングデータベースへのクエリは、運用しているデータベースに影響を与えることがない。

反対にデメリットは、データを最新状態に保たなければならないという点だ。適時性を採用すると、ややこしくなることもある。 最も簡単なのは、レポーティングデータベースを夜間更新にすることだ。昨日のデータがあればOKなレポートだと、これでまるっとうまくいく。 もっとタイムリーなデータが必要であれば、運用データベースへの変更がレポーティングデータベースに波及しないよう、メッセ—ジングシステムを用いればよい。こうなるとちょっと複雑になってくる。だが、データはより新しいものとなる。 これでレポートはあまり古くないデータを使うことが出来るようになる。 いま現在のデータが欲しいような場合には別途、特別なレポートを生成することができる。

代替案として、ビューを用いることもできる。ビューは運用データをカプセル化する上、正規化されてなくともよい。 しかしこれだと、運用データベースとレポーティングデータベースを分離することが出来ない。 もっと深刻なのは、どういったビューを生成するかには限界があるため、 ドメインモデルに振る舞いを持たせる利点を得ることは出来ない点である。

レポーティングデータベースとドメインモデルの組み合わせを例として挙げたが、 このアプローチは、データベースをカプセル化するような場所ならばどこにでも適用できる。 これをSOAの目的のひとつだと見なしている人も多い（★）。

comment

  • 2004-04-05 (月) 13:43:09 ‘’[[kdmsnr]]’’ : 最後のあたり、ぐだぐだです。理解できてない。何がSOAなのだ？
  • 2004-04-06 (火) 15:14:45 ‘’[[keis]]’’ : 最後のところは、「データベースのカプセル化をSOAの目的のひとつと見なしている人も多いが（別にSOAでなくても可能なんだよ）」という意味ではないでしょうか。
  • 2004-04-06 (火) 16:36:13 ‘’[[kdmsnr]]’’ : 「目的」という言葉がいけないんですかねえ。いまいちよく分かりません。SOAの目指すところ？