architecturehttp://www.martinfowler.com/bliki/ReportingDatabase.htmlドメインモデルを使っているとき、アドホックなSQLへの対応はどうすればよいか?’’’ドメインモデルの利点として、アプリケーション内のデータに重要な振る舞いを与えるという点が挙げられる。データのレポートが欲しいのであれば、ドメインモデルは非常に便利である。多くのレポーティングツールはSQL対応のデータベースを前提としている。ドメインモデルには対応していないのだ。ドメインモデルが出来ることは何だろう?最初にやらなければならないのは、アドホックなレポートの必要性を問うことだ。アドホックなレポートが多すぎるというのは、誰もその必要性をちゃんと確認していないというだけのことである。本当に必要かどうかをチェックすれば、アドホックなレポートがどれだけ「不自然なもの」かが分かるだろう。それから、ドメインモデルに対してコーディングを行うことで、アドホックなレポートに十分対応できるということにも気付くはずだ。レポートは素早く作成されることが必要なのであり、ユーザーはいかに作られるかなど気にしていない(どうせSQLを自分で入力したいとも思っていないだろう)。これは、すべてのケースにあてはまるわけではない。SQLベースのレポーティングツールが好きで、直接使いたいと思っているようなパワーユーザーがいる。いった場合のうまいやり方は、レポーティングデータベースを構築することだ。レポ—ティングデータベースは実際に運用しているデータベースとは別のデータベースである。レポ—ティングデータベースでは、ドメインモデルに対して行ったコードが走っている。ドメインモデルから生成されたデータをレポーティングデータベースに入れることができる。これにはいくつかのメリットがある。ドメインモデルを経由しているため、ドメインモデル内でデータを生成してから、レポーティングデータベースにデータを入れることが出来る。レポーティングデータベースはリードオンリーなので、最適化する必要がない。レポーティングデータベースの構造は、レポートをいかに簡単に作れるかにフォーカスを当てて設計することができる。開発者はレポーティングデータベースに影響を与えることなく、運用しているデータベースをリファクタリングすることができる。レポーティングデータベースへのクエリは、運用しているデータベースに影響を与えることがない。反対にデメリットは、データを最新状態に保たなければならないという点だ。適時性を採用すると、ややこしくなることもある。簡単なのは、レポーティングデータベースを夜間更新にすることだ。昨日のデータがあればOKなレポートだと、これでまるっとうまくいく。タイムリーなデータが必要であれば、運用データベースへの変更がレポーティングデータベースに波及しないよう、メッセ—ジングシステムを用いればよい。なるとちょっと複雑になってくる。データはより新しいものとなる。これでレポートはあまり古くないデータを使うことが出来るようになる。いま現在のデータが欲しいような場合には別途、特別なレポートを生成することができる。代替案として、ビューを用いることもできる。ビューは運用データをカプセル化する上、正規化されてなくともよい。これだと、運用データベースとレポーティングデータベースを分離することが出来ない。ドメインモデルに振る舞いを持たせる利点を得ることは出来ない点である。このアプローチは、データベースをカプセル化するような場所ならばどこにでも適用できる。これをSOAの目的のひとつだと見なしている人も多い(★)。最後のあたり、ぐだぐだです。最後のところは、「データベースのカプセル化をSOAの目的のひとつと見なしている人も多いが(別にSOAでなくても可能なんだよ)」という意味ではないでしょうか。「目的」という言葉がいけないんですかねえ。gmail.combliki-ja。