8

明確なドメイン モデルを持つ比較的新しい Web ベースのアプリケーションを、より CQRS スタイルのシステムに変換しようとしています。私の新しいアプリケーションは、基本的に古い既存のシステムを強化したものです。

私の組織の既存のシステムは、会社全体のサイロに存在する膨大な数のアプリケーション (カオス メソッドによって開発された) によって更新される一連の共通データベースを共有しています。（現状では、社内の 1 人ですべてを特定できる人はいないと思います。）

したがって、私の質問は、私のアプリケーションの読み取りモデルに関するものです。さまざまなステータスの変更、一般的なユーザー データなどは、私の制御外の他のアプリケーションによって更新されるため、外部の更新を処理できるように読み取りモデルを構築するのに最適な方法は何ですか?

これまでに次のことを検討しました。

  1. レガシーおよび新規のすべてのテーブルを読み取る読み取りモデルのデータベースにビューを作成します
  2. 既存のテーブルにトリガーを追加して、新しい読み取りモデル テーブルを更新する
  3. データベース (CLR Stored proc/etc [SQL サーバー]) にコードを追加して、読み取りモデルの外部データストアを更新します。
  4. 希望を捨てる

これにどのようにアプローチするかについての一般的なコンセンサスは何ですか? すべてをゼロから完全に書き直さずにレガシーシステムに秩序をもたらすことができると考えるのはばかげていますか?

4

3 に答える 3

1

私はかつて同様の状況にありましたが、次の手順は私が行った方法です。

レガシー システムを改善し、よりクリーンなコード ベースを実現するための鍵は、書き込みの責任を引き継ぐことです。ただし、野心的になりすぎないでください。インターフェイスやコントラクトの変更が発生し、最終的な展開が危険になる可能性があります。

  1. すべての書き込みが SQL の直接更新以外の方法で実行される場合は、可能な限り後方互換性を維持してください。それらを、新しく開発されたコマンド ハンドラーのアダプター/クライアントとして使用します。

  2. 書き込みの一部は SQL の直接の更新ですが、制御
    できません 担当チームに、新しいインターフェイス/契約に変更できるかどうか尋ねてください。
    いいえの場合は、手順 3 を参照してください。

  3. 結果整合性を許容できるかどうか、SQL 更新をデータベース プロシージャに置き換える意思があるかどうかを尋ねます。
    はいの場合は、すべての SQL 更新を手順に入れ、展開をスケジュールして、手順 4 を参照してください。
    いいえの場合は、それらをリファクタリングに含める必要があります。

  4. 手順を変更し、SQL 更新を挿入イベントに置き換えます。そして、イベントをロールして公開するバックエンド ジョブを開発します。これらのイベントをサブスクライブする新しいアプリケーションを作成して、コマンド ハンドラーにコマンドを発行します。

  5. コマンド ハンドラーからイベントを発行し、それらを使用して、他のアプリケーションが使用していたテーブルを更新します。

  6. レガシー システムの次の部分に移動します。

于 2014-12-24T04:56:45.240 に答える