13

この質問をする理由は、これらのさまざまな概念をすべてつなぎ合わせる方法を考えていたからです。DDD、依存性注入、CQRS、SOA、MVC などに関する多くの例と議論がありますが、それらすべてを柔軟な方法でまとめる方法についての例はそれほど多くありません。

私の目標：

  1. ほとんど、またはまったく変更を加えなくても自立できるモジュールを開発する
  2. UI の変更または作り直しは、できるだけ簡単であるべきです (つまり、UI はできる限り少なく、「ばかげた」ものであるべきです)。
  3. 文書化されたパターンと原則を使用する

具体的な質問をしやすくするために、メイン アーキテクチャは次のようになります。

従業員管理の例

この例は、従業員にメモを追加する方法を示しています。従業員管理は 1 つの限定されたコンテキストです。Employee にはいくつかのプロパティがありICollection<Note>ます。

バインドされたコンテキストは、私の理解では、コードを分離するロジックの場所です。各 BC はモジュールです。ほとんどの場合、必要に応じてそれぞれが独自の UI を保証できることがわかります (つまり、一部のモジュールは Windows phone で利用できるようになる可能性があります)。

ドメインはすべてのビジネス ロジックを保持します。

インフラストラクチャには、リポジトリの実装と、メールを送信するサービス、ドメインに属さないファイルとユーティリティを保存するサービスが含まれています。複数のドメインで使用する必要のある一般的なサービス機能 (電子メールの送信など) を、複数の BC で同じことを実装するコードを保存するために参照できる一種の API として作成することを考えています。

クエリ レイヤーは、オブジェクトを取得するためにリポジトリで必要な GetById を除くすべてのクエリを保持します。クエリ レイヤーは他の永続化インスタンスをクエリできますが、おそらく UI ごとにいくつか変更する必要があります。

Wcf または Web Api は、私のアプリケーション レイヤーのようなものです。外部ではなく、インフラストラクチャに属している可能性があります。このサービスは依存関係もセットアップするため、UI が行う必要があるのは、情報を求めてコマンドを送信することだけです。

プロセスは青い矢印から始まります。ほとんどの情報が含まれているため、モデルを読み取ります。

ステップ 1 では、この例の EmployeeDto は、メモを作成する必要がある従業員に関するユーザー情報を表示するための従業員プロパティの一部です (新しい経験に関するメモなど)。

したがって、質問は次のとおりです。

  1. このようなレイヤード アーキテクチャの実装には、本当に多くのマッピングが必要ですか?
  2. このようなメインロジックを実行するためにWcfサービスを使用することをお勧めします（またはスマートです）（実際には私のアプリケーションサービスです）
  3. UI レイヤーにドメイン オブジェクトを持たない Wcf の代替手段はありますか?

  4. この実装に問題はありますか。注意すべき秋のピットはありますか？

  5. これらすべての概念がどのように連携するかを理解するのに役立つ、推奨する良い例はありますか.

更新: 有料の本 (もう少し時間が必要です) を除いて、ほとんどの記事を読みました (かなりの量を読みました)。それらはすべて非常に優れた指針であり、より多くの Wcf をアダプターとして考える方法は、質問 2 に対する良い答えのようです。JGauffins が彼のフレームワークに取り組んでいることも、私がそのルートに行くことを計画している場合、非常に興味深いものです。 .

ただし、以下のコメントのいくつかで述べたように、いくつかの例は、イベントおよび/またはコマンド ソーシング、メッセージ バスなどを推奨または実装する傾向があると感じています。私にとって、そのレベルのスケーリングを今すぐ計画するのはやり過ぎです。多くのビジネス アプリケーションと同様に、これは "大" (内部アプリケーションに関しては、最大で数千と考えてください) の数のユーザーであり、イベントやコマンドを実装する必要があるという意味で高度に協調的なドメインではありません。それに対処するために、多くの場合、CQRS に関連付けられているキュー。

以下の回答に基づいて、私が始めるアプローチは、上記のモデルと次のような回答に基づいています。

  1. マッピングに対処するだけです。長所は短所を上回ります。

  2. アプリケーション サービスをインフラストラクチャに戻し、Wcf を「アダプター」と見なします。

  3. コマンド オブジェクトを使用して、アプリケーション サービスに送信します。ドメイン オブジェクトでドメインを汚染しない。

  4. 複雑さを抑えるために、今のところ、イベント/コマンド ソース、メッセージ バスなどを使わずに管理しようとしています。

さらに、Udi Dahan による CQRS に関するこのブログ投稿にリンクしたかっただけです。本当に必要でない限り、このようなものは複雑さを抑えていると思います。

4

2 に答える 2

10

  1. マッピングとレイヤーの間にはトレードオフがあります。特定のマッピングが存在する理由の 1 つは、適切な抽象化が利用できないか実行できないためです。その結果、マッピングを推測するフレームワークを実装しようとするよりも、レイヤー間を明示的にマッピングする方が簡単なことがよくありますが、余談になります。これは、問題の哲学的議論にかかっています。

  2. WCF または WebAPI サービスは非常に薄い必要があります。六角形アーキテクチャのアダプターと考えてください。すべてをアプリケーション サービスに委任する必要があります。混乱を引き起こすサービスという用語の混同があります。全体として、WCF または WebAPI の目標は、ドメインを HTTP などの特定のテクノロジに "適応させる" ことです。WCF は、DDD 用語でオープン ホスト サービスを実装していると考えることができます。

  3. HTTPが必要な場合の代替手段であるWebAPIについて言及しました。最も重要なことは、この適応層の役割に注意することです。あなたが述べているように、UI を DTO に依存させ、一般的には WCF や WebAPI などで実装されたサービスの契約に依存させるのが最善です。これにより、物事がシンプルになり、オープン ホスト サービスの利用者に影響を与えることなく、ドメインの実装を変更することができます。

  4. 不必要な複雑さに常に注意を払う必要があります。レイヤリングはトレードオフであり、時にはやり過ぎになることもあります。たとえば、主に CRUD であるアプリでは、これほどレイヤーを重ねる必要はありません。また、前述のように、WCF サービスをアプリケーション サービスと考えないでください。代わりに、トランスポート テクノロジとアプリケーション サービスの間のアダプタと考えてください。次に、ドメインが DDD で実装されているかトランザクション スクリプト アプローチで実装されているかに関係なく、アプリケーション サービスをドメインのファサードと考えてください。

  5. 私が理解するのに本当に役立ったのは、六角形のアーキテクチャに関する参照記事です。このようにして、ドメインをコアと見なし、その周りにレイヤーを重ねて、ドメインをインフラストラクチャとサービスに適応させることができます。あなたが持っているものは、すでにこれらの原則に従っているようです。これらすべてに関する優れた詳細なリソースは、Vaughn Vernon によるドメイン駆動設計の実装、特にアーキテクチャに関する章です。

于 2012-11-27T21:30:20.810 に答える
2

このようなレイヤード アーキテクチャの実装には、本当に多くのマッピングが必要ですか、それとも何か見落としているのでしょうか?

はい。問題は、それが同じオブジェクトではないということです。これは同じオブジェクトの異なる表現ですが、ユースケースごとに特化しています。ビュー モデルには GUI を更新するためのロジックが含まれており、DTO は転送に特化しています (転送を容易にするために正規化される場合があります)。などなど。同じように見えるかもしれませんが、実際にはそうではありません。

もちろん、すべての適応を単一のクラスに入れようとすることもできますが、アプリケーションが大きくなったときにそれを扱うのはあまり楽しくありません。

このようなメインロジックを実行するためにWcfサービスを使用することをお勧めします（またはスマートです）（実際には私のアプリケーションサービスです）

ある種のネットワーク層が必要です。すべてのクライアント アプリケーションがデータベースにアクセスできるようにするわけではありません。データベース スキーマをいじると、メンテナンスの悪夢が発生します (一部のクライアントがまだ古いバージョンを実行している場合)。

サーバーを使用すると、バージョンの違いを維持するのがはるかに簡単になります。

WCF サービス定義は、一度使用すると定数として扱う必要があることに注意してください。すべての変更は、新しいインターフェイス (たとえばMyService2) で定義する必要があります。

UI レイヤーにドメイン オブジェクトを持たない Wcf の代替手段はありますか?

私のフレームワークを見てください。投稿開始: http://blog.gauffin.org/2012/10/writing-decoupled-and-scalable-applications-2/

この実装に問題はありますか。

私が見ることができるわけではありません。概念とその使用方法をかなりよく理解しているようです。

注意すべき秋のピットはありますか？

クエリとコマンドで怠惰になろうとしないでください。いくつかのユースケースに適合するように、もう少し汎用的にしないでください。アプリケーションが成長すると、戻ってきてあなたを悩ませます。クラスが小さいほど、保守が容易です。

これらすべての概念がどのように連携するかを理解するのに役立つ、推奨する良い例はありますか.

リンクされたブログ投稿とそのシリーズの他のすべての記事。

于 2012-11-28T16:18:37.727 に答える