サービスがSOAでデータベースを共有することは悪い習慣ですか？

最近、私はHohpeとWoolfのEnterprise Integration Patterns、Thomas ErlのSOAに関する本を読んでおり、Udi Dahanらによるさまざまなビデオやポッドキャストを見てきました。CQRSおよびイベント駆動型システム。

私の職場のシステムは、高い結合に悩まされています。各システムには理論的に独自のデータベースがありますが、それらの間には多くの結合があります。実際には、これは、すべてのシステムが使用する1つの巨大なデータベースがあることを意味します。たとえば、顧客データのテーブルが1つあります。

私が読んだことの多くは、各システムがデータベースのみを使用し、メッセージングを使用して他のすべてのシステムに更新が伝播されるように、データの非正規化を示唆しているようです。

これはSOAの境界を強化する方法の1つだと思いました-各サービスには独自のデータベースが必要ですが、それを読んでみました：

/programming/4019902/soa-joining-data-across-multiple-services

そして、これは行うのが間違っていることを示唆しています。

データベースを分離することは、システムを分離する良い方法のように見えますが、今は少し混乱しています。これは良いルートですか？SOAサービス、DDDバウンドコンテキスト、アプリケーションなどでデータベースを分離することをお勧めしますか？

デカップリングは、本当に分離がある場合にのみ機能します。注文システムがあるかどうかを検討してください。

• 表：顧客
• 表：注文

それがあなたが持っているすべてであるならば、それらを分離する理由はありません。一方、これがある場合：

• 表：顧客
• 表：注文
• テーブル：CUSTOMER_NEWSLETTER

次に、ORDERとCUSTOMER_NEWSLETTERは2つのまったく異なるモジュール（注文とマーケティング）の一部であると主張できます。おそらく、これらを別々のデータベース（テーブルごとに1つ）に移動し、両方のモジュールが独自のデータベース内の共通のCUSTOMERテーブルへのアクセスを共有するのが理にかなっています。

そうすることで、各モジュールを単純化できますが、データレイヤーの複雑さが増します。アプリケーションがどんどん大きくなるにつれて、分離することの利点がわかります。互いに関係のない「データアイランド」がますます増えます。ただし、すべてのモジュールを横断するデータが常に存在します。

それらを異なる物理データベースに配置するかどうかの決定は、通常、バックアップの頻度、セキュリティ制限、異なる地理的場所への複製などの現実世界の制約に基づいて行われます。これは、異なるスキーマまたはビューでより簡単に処理できます。

私が働く場所にはESBがあります6つの異なるアプリケーション（または「エンドポイント」と言う必要があります）が接続されています。これらの6つのアプリケーションは、2つのデータベースインスタンス上の3つの異なるOracleスキーマで動作します。これらのアプリケーションのいくつかは、関連しているためではなく、外部インフラストラクチャによってデータベースインフラストラクチャが管理されており、新しいスキーマの取得には永遠にかかるため（同じように、DBAアクセスはありません）、同じスキーマで共存しています...本当に時間がかかるので、ある時点で、既存のスキーマを「一時的に」再利用して開発を続けることを考えました。データの「分離」を強制するために、テーブル名には接頭辞が付けられます（たとえば、顧客の場合は「CST_」）。また、いくつかの正当な理由のために絶対に変更できないスキーマを使用する必要があります...それは奇妙なことです。もちろん、いつものように、「一時的に」

さまざまなアプリケーションがそれぞれのデータベーススキーマに接続し、独自のPL / SQLパッケージで動作し、アプリケーションドメイン外のテーブル/データと直接対話することを絶対に禁止します。

ESBに接続されたアプリケーションの1つがドメイン外の情報を必要とする場合、その情報が実際に同じスキーマにある場合でも、ESBの関連サービスを呼び出してデータを取得します。SQL要求の1つ。

アプリケーションドメインを異なるスキーマ/データベースに分割できるようにするため、また、ESBのサービスが発生した場合でも適切に機能するようにするためです（まもなくクリスマスになり、指を修正します）

さて、これは外部からは奇妙でひどいように見えるかもしれませんが、それには理由があります。1つ以上のデータベースがそれほど重要ではないことを示すために、この具体的な経験を共有したいだけです。待って！、多くの理由で（スコットホイットロックの+1、バックアップに関する最後の段落を参照し、myaがトラブルにつながるように）、SOAサービスを適切に設計することも同様に重要です。少なくとも私の意見では、 DBAではありません。最終的に、すべてのデータベースは「エンタープライズデータウェアハウス」に属しますか？

最後に、Scott Whitlockの最後の段落、特にこれを言い換えません。

懸念を分離するためだけに、テーブルを異なる物理データベースに分離しません。

非常に重要です。理由がない場合はしないでください。

データ統合によるソフトウェアアーキテクチャの最悪の悪夢と、これまで遭遇したこのタイプの混乱に対する最良の武器を見てきました。DDDスタイルの境界付きコンテキストです。これは、ある意味で「SOAが正しく行われた」からそれほど遠くありません。

ただし、データ自体は問題を攻撃する最善の方法ではありません。予想される/必要な動作に焦点を当て、データを重要な場所に持ってくる必要があります。このように重複する可能性がありますが、これは通常、ほとんどの場合、データ統合アーキテクチャに関連付けられているシステム進化のブロックと比較して問題ではありません。

簡単に言うと、疎結合システムを探している場合は、データを結合したままにしないでください。「lingua franca」として機能する、カプセル化されたシステムと、その間によく構造化された通信チャネルを探します。

データベースを分離し、データベース間でデータの一貫性を保つことは、エキスパートレベルのタスクです。現在のシステムが回避するように設計されているため、間違って簡単に重複などの問題が発生する可能性があります。率直に言って、稼働中のシステムを使用してこれを行うことは、ユーザーにとって実質的な価値のない新しいバグを導入することを保証します。

正しく行われた場合、ビジネス上の懸念を異なるデータベース（または少なくとも異なるスキーマ）に分離することは美徳です。

Martin FowlerのCQRSパターンの説明をご覧ください。

ニーズがより高度になるにつれて、[CRUDデータストアのような情報システムを扱う]から着実に遠ざかります... CQRSが導入する変更は、その概念モデルを更新と表示のために個別のモデルに分割することです...かなりのバリエーションの余地がありますここに。インメモリモデルは同じデータベースを共有できます。この場合、データベースは2つのモデル間の通信として機能します。ただし、個別のデータベースを使用して、リアルタイムのReportingDatabaseによってクエリ側のデータベースを効率的に作成することもできます。この場合、2つのモデルまたはそれらのデータベース間に何らかの通信メカニズムが必要です。

そしてNServiceBusの建築原則：

コマンドクエリの分離

この問題を回避するソリューションは、システムレベルでコマンドとクエリを分離し、クライアントとサーバーのレベルを超えます。このソリューションには、クライアントとサーバーの両方にまたがる2つの「サービス」があります。1つはコマンド（作成、更新、削除）を担当し、もう1つはクエリ（読み取り）を担当します。これらのサービスはメッセージを介してのみ通信します- 一方は他方のデータベースにアクセスできません...

そして、コマンドとクエリの責任分離（CQRS）

コマンドとクエリの責任分離

ほとんどのアプリケーションは、データを書き込むよりも頻繁にデータを読み取ります。その声明に基づいて、読み込むデータベースを簡単に追加できるソリューションを作成することをお勧めしますか？では、読み取り専用のデータベースを設定したらどうでしょうか？さらに良い。データベースを読みやすいように設計したらどうでしょうか？CQRSアーキテクチャで説明されているパターンに基づいてアプリケーションを設計すると、データの読み取りがスケーラブルで高速なソリューションが得られます。