.NETアプリケーションのシステムアーキテクチャ設計

Question

以下のアーキテクチャ図を参照してください。私のクライアントがプロジェクトに対して提案したものです。プロジェクトは非常に大きなサイズで、現在はデータベース操作のためのADO.Net（ストアドプロシージャ）を使用したSOAです。

それは余分なレイヤを追加し、追加もパフォーマンスの問題を作成することができように私は、メッセージングサービスを使用するには少し消極的です。

私の下のクエリ

にご入力をお願い致します

（1）私たちは現在のアーキテクチャ に直面している主な問題 - 長時間実行stopred手順は、それは同様に他の操作を遅く実行しているとき。そのため、1つの大きなデータベースを複数のデータベースに分割しています。 - アプリケーションロジックは現在かなり複雑です。複雑なクエリを持つストアドプロシージャがあります。

（1）EFを使用してADO.Netを完全に置き換えることは可能でしょうか。約20のテーブルを含む複雑な（または大きな）クエリを持つストアドプロシージャを置き換える方法。

（2）私たちが複数のデータベースを持っているときに切断を維持するには、これは非常に難しいと思います。

（3）同様のアーキテクチャーを使用してサンプルやアプリケーションを試してみてください。パイロットアプリケーションを作成し、現在のデータベースでテストすることができます。

---

代わりに、私は/更新/挿入するために、すなわち（各アプリケーションが一般的なリポジトリとEFを使用してデータベースにデータを書き込み、アプリケーションがお互いに話をしたいときにマイクロサービスアーキテクチャの一種である、アーキテクチャの下に好みますデータをフェッチする）、メッセージングサービスを使用します。どんなアプローチが良いか教えてください。私の経験で

Answer 1

は、メッセージングサービスを使用すると、長時間実行されている手順で）1で見ている問題の多くを解決し、実際にしています。

以前の大規模プロジェクトでは、ActiveMQとRabbitMQをメッセージングサービスとして使用しました。

1つのシナリオでは、メッセージングサービスを使用してブロックを削除できました。そのため、ストアドプロシージャを呼び出す代わりに、後で処理できるキューにジョブをダンプしました。

別のシナリオでは、ビジネスロジックを同一の労働者に分割することで、これをさらに改善することができました。ジョブは、メッセージングサービスを使用してラウンドロビンファッションで各従業員に配布されました。これは事実上Competing Consumers Patternの実装でした。以下は、良い説明を与える：

https://www.rabbitmq.com/tutorials/tutorial-two-python.html

Answer 2

プロジェクトは非常に大きなサイズであり、現在ここにそのSOA

を使用すると、キーワードがかなり大きいです。大規模なアプリケーションはしばらくしてから乱雑になる傾向があり、分離が重要です。あなたがそれを行うだろうか

は、あなたのチームは知っていて、慣れているかに依存します。メッセージングとCQRSに基づいて、私の経験の建物の用途で

を使用すると、物理的に事業領域を分離として長年にわたって地面を保持する傾向があり、APIは、メッセージングサービス契約よりもはるかにきめ細かいです。

は私見それは彼ら緊密に結合させることが容易になりますようMVCアプリケーションにビジネス層を露出するのは間違いです。代わりに、それらからサービスを呼び出します。

サービスの人々は、彼らがあまりにも良いデザインを持っている必要があることを忘れているので、ほとんどの悪い評判を持っています。それらを成長させたり、すべてを行うことができる神の授業にさせたりしないでください。それらを小さくしてよく定義してください。私はCRUDアクションの代わりにビジネスアクションを定義するサービスを好んでいます。特に、ビジネスレイヤーを保護し、データストアの一貫性を向上させたい場合に適しています。