MVC Webアプリケーションのためのドメイン駆動設計対データベース駆動型デザイン

Question

従来のWebフォームアプリケーションを完全に新しいMVCアプリケーションに拡張/変換しています。展開は、技術の観点からも、ビジネスユースケースです。レガシーアプリケーションは、データベース駆動型デザイン（DBDD）です。たとえば、オペレータ、スーパーバイザ、ストアなどの種類の従業員がいる場合は、新しいタイプを追加する必要がある場合は、いくつかのテーブルとVoilaにいくつかの行を追加して追加するだけで、UIは自動的に新しいものを追加/更新するためのすべてを持ちます。従業員の種類 しかしながら、層の分離はそれほど良くない。

新しいプロジェクトには2つの主な目標があります

• 拡張性（現在および将来のパイプライン要件の場合）
• パフォーマンス

  データベース駆動型設計（DBDD）を交換する新しいプロジェクトを、拡張性の要件を念頭に置いてドメイン駆動設計（DDD）を登録する予定です。ただし、データベース駆動型デザインからドメイン駆動型デザインへの移動は、それをレガシーDBDDアプリケーションのパフォーマンスと比較すると、パフォーマンス要件に逆に影響を与えるようです。従来のアプリケーションでは、UIからのデータの呼び出しはデータベースと直接対話し、データレーダーの形式または（場合によって）データセットの形式で返されます。

  現在のDDDが適切な場合は、データの呼び出しがビジネス層とデータアクセス層を介してルーティングされます。これにより、各呼び出しはビジネスオブジェクトとデータアクセスオブジェクトを初期化することを意味します。単一のUIページでは、さまざまな種類のデータが必要になり、これはWebアプリケーションである各ページが複数のユーザーから要求される可能性があります。また、MVC Webアプリケーションはステートレスであるため、各要求はそれぞれ毎回ビジネスオブジェクトとデータアクセスオブジェクトを初期化する必要があります。 そのため、MVCステートレスアプリケーションのように思われます.DBDDは、パフォーマンスのためにDDDに優先されます。

  またはDDDの両方を達成するための方法で、DDDが提供する拡張性とDBDDが提供するパフォーマンスは？

Answer 1

更新がドメインモデルを介していると、まだ読み取られたコマンドクエリの分離の形式を検討しましたか？完全な吹き付けDDDは必ずしも適切ではありません。

Answer 2

"現在厳格なDDDを持つデータの呼び出しは、ビジネス層とデータアクセスレイヤーを介してルーティングされます。"

これが本当であるとは思わない、そしてそれは確かに実用的ではありません。私はこれが読むべきだと思います：

現在厳密なDDDが整って、トランザクションの呼び出しは、ビジネス層とデータアクセスレイヤーを介してルーティングされます。

画面に表示する必要があるデータを取り出すために直接データアクセスレイヤを呼び出すことができないということはありません。その動作に基づいて設計されているドメインモデルを呼び出す必要があるデータを修正する必要がある場合にのみです。私の意見では、これは重要な区別です。あなたがドメインモデルを通してすべてをルーティングするならば、あなたは3つの問題を抱えています：

1. 時間 - それは利益なしで機能を実装するのにはるかに長くあなたを連れて行くでしょう。
2. モデル設計 - あなたのドメインモデルは、動作ではなくニーズに応えるために形状から曲がっています。
3. パフォーマンス - 追加のレイヤーのためではなく、あなたが照会から直接的にできる限り早く集約されたデータを早く得ることができないからです。すなわち、特定の顧客に配置されたすべての注文の合計価値を考慮して、顧客のために繰り返し、合計を処理することよりもこれに対するクエリを書くことがはるかに速い。

   ChriseyRe2000が言及されているように、CQRSはこれらの正確な問題を解決することを目指しています。

Answer 3

DDDを使用すると、シナリオでは著しいパフォーマンスへの影響を与えないでください。あなたが心配しているのは、データアクセスの問題のようなものです。あなたはそれをと呼びます

ビジネスオブジェクトとデータアクセスオブジェクトの初期化

高価なのはなぜですか？どのデータアクセスメカニズムを使用していますか？ リレーショナルデータベースに格納されている長寿命のオブジェクトを持つDDDは、通常、ORMで実装されています。適切に使用されている場合は、ほとんどのアプリケーションのパフォーマンスに影響を与える場合は、ormがほとんどありません。実証済みのボトルネックがある場合は、必ずアプリの最もパフォーマンスに敏感な部分を生のSQLに切り替えることができます。

それは価値があるのに対して、Nhibernateはアプリケーションの起動時に1回だけ初期化する必要があります。その後、通常のデータリーダーと同じADO.NET接続プールを使用します。それで、それはすべて適切なマッピング、フェッチし、戦略を取得し、 'n + 1選択'のような古典的なデータアクセスの間違いを回避します。