問題タブ [bounded-contexts]

部分ビューの使用方法を理解しています。また、ビューでそれらを設定する方法については、Ajax.ActionLink と Ajax.BeginForm を理解しています。各部分ビューには独自のコントローラーがあると想定しています。ここでは、境界付けられたコンテキストを考えています。各部分ビューでは、独自のコントローラーを介して独自の境界付けられたコンテキストと通信できるためです。

私が見逃している作品は次のとおりです。

1. 部分ビューを「マスター ビュー」(または保持ビュー) に含め、これらの各部分ビューを別々のコントローラー アクションに個別に投稿し、「マスター ビュー」または保持ビューをロードせずに部分ビューを更新する方法.
2. 「マスター」ビューまたは保持ビューには独自のコントローラーが必要です。マスターコントローラーがビューをリロードしないようにし、マスターコントローラーのアクションメソッドによって生成されたビューにこれら2つの部分への参照を保持させたいビュー。

考えられるアプローチは 2 つあります。1 つは「Ajax」を使用することです。もう 1 つは、ストレートな jQuery を使用して、クライアント側からこのすべてのやり取りを手動で処理することです。

私がやろうとしていることは両方の方法で可能ですか、それともこのタイプの複合UI構築に「より適した」方法ですか?

これまでのところ、私が見た唯一のものは、ページ上のシングルを更新する Ajax.ActionLink を介したリンクや、div を a部分的なビュー。

ギャンブラーが賭けのポートフォリオを維持し、時間の経過に伴う利益/損失を追跡できるようにするクライアント用のシステムを構築したとします。このシステムは、さまざまなスポーツへの賭け、勝利を他の賭けにロールオーバーするなど、多くの複雑なドメイン ロジックをサポートしています。

次に、私のクライアントは、予想屋のアイデアをサポートしたいと考えています。予想屋は実際にギャンブルをするのではなく、何を賭けるべきかについてのヒントである「予想シート」を作成します。チップ シートにはさまざまな種類があります。ベット可能なイベントに関するチップを含むものもあれば、競馬に関するチップのみを提供するものもあります。私のクライアントは、システムがギャンブラーのパフォーマンスを追跡するのと同じ方法で予想屋のパフォーマンスを追跡することを望んでいます。さらに、さまざまな種類の予想屋内および異なる種類の予想屋の間でパフォーマンスを比較できるようにします (たとえば、最高の競馬予想屋は誰ですか?彼らは一般的にサッカーの予想屋よりも優れたパフォーマンスを発揮しますか?)

現在、ドメイン言語はギャンブラーと予想屋の間で完全に異なり、ギャンブラーのポートフォリオには存在しない予想シートの追加の分類があります。これは、これらが別個の境界付けられたコンテキストであることを示唆しています。ただし、どちらも時間の経過とともにパフォーマンスを追跡するため、多くの共有ロジックがあります。

だから私の質問は：

1. これらは本当に別個の境界付けられたコンテキストですか? 私は、ギャンブラーのコンテキストに分類を追加することに慎重です (滑りやすい坂道のように感じます)。
2. それらが異なるコンテキストである場合、次のことを行う必要があります。
   • それらの間でパフォーマンス追跡ロジックを共有しますか (つまり、DLL、jar などを共有しますか)? これにより、コンテキスト間の緊密な実装結合が作成され、正しくないと感じられます。
   • パフォーマンス追跡ロジックをギャンブル境界コンテキストに残し、分類ロジックを予想屋バウンダー コンテキストに配置し、ギャンブル コンテキストにパフォーマンス追跡を依頼しますか? この場合、予想屋のコンテキストがギャンブルのコンテキストにコマンドを送信するように見えますが、これも間違っているように感じます (私はイベントの方が快適です)。
   • 何か他のことを...両方のコンテキスト間で通信し、相互に関連付けるある種の合成レイヤーを行いますか?

明確化

ギャンブラーのポートフォリオと予想屋の予想シートはほとんど同じです。唯一の違いは、予想シートを分類できることです (例: 競馬、サッカーなど)。

パフォーマンス追跡とは、ポートフォリオ/ヒントシートの利益/損失を測定することです。

私はDDDの原則を使用してアプリケーションを作成しています。できる限りすべてを考えた後、私はバウンドコンテキストの作成を開始します。最終的な構造はまだ設定していませんが、現時点では、アプリケーションは次の制限されたコンテキストで構成されています。

1. 従業員の管理
2. 購入
3. 記録
4. 報告

これをできるだけプラグインできるようにしたいので、たとえば、別々に開発して保守することができます。おそらく、それらはWCFまたはWebAPIのいずれかを公開してそれらと対話します。

単純なCQRSパターンのUdiDahans実装を使用します。これは高度なコラボレーションアプリではないため（ユーザー数が1000人未満で、同じ小さなデータセットを編集する可能性が低いため）、イベントソーシングやメッセージバスなどを使いたくありません。不必要な複雑さをたくさん追加します。

だから質問に：

従業員と部門のエンティティはすべてのBCに共通ですが、それをどのようにモデル化するのですか？

部門は組織構造の一部であるため、従業員管理BCでは、従業員は部門で作業し、部門を管理でき、これまでに取り組んだ部門の履歴があります。

購買では、BC商品は部門から購入され、部門に配送されます。サプライヤーは、部門ごとに異なる契約を結んでいます。

アーカイブでは、一部の情報がアーカイブされ、部門に関連付けられます。

同じことが従業員にも当てはまります。

制限されたコンテキストからデータを永続化する方法は？

それらは同じデータベースにマップすることも、それぞれに独自のデータベースを持たせることもできます。

私がこれまでにしたいくつかの考え

モデル化の方法
「会社」または「組織」と呼ばれるもう1つのBCを作成し、そこで部門を管理する必要がありますか？

上記のUdiDahansの記事に従って、各BCの部門エンティティと従業員エンティティを、そのBCに必要なフィールドと動作だけで作成する必要があります。これは理にかなっているように聞こえますが、実際にこれをどのように使用するかを考えているので、理解できません。他の場所で管理されている部門にアクセスする必要がありますが、BCを混在させずに、これをどのように正確に行うのですか？

使い方？
クエリを実行して、どこかから部門のリストを取得したとします。UIには、購入したい部門のリストも表示されます。これはこの部門の最初の購入であるため、購買BCはこの部門についてまだ知りません...したがって、購買BCの部門オブジェクトは、他のBCから維持されたデータで満たされます-では、これをどのように保持しますか？配送先住所や請求書住所などの情報が存在しない場合は、追加する必要がありますか？

次に、「部門UIの登録」で、すべてのBCで「RegisterDepartment」サービスを呼び出し、UI（MVCコントローラー）を介して行われたすべての変更と同期していることを確認する必要がありますか？

従業員も同じです。どの従業員が購入したか、アーカイブに何かを入れたか知りたいです。したがって、どういうわけか、これらのBCにも従業員オブジェクトが必要ですが、別のBCからそれらを管理します。

永続
化上記の課題のいくつかは、データベース内の同じテーブルにさまざまな従業員オブジェクトをマッピングすることで解決できます。PurchasingBCとArchiveBCは新しい従業員を登録できませんが、そこにいる従業員に情報を追加し、同じデータベース内の他のオブジェクトに結び付けます。そうすれば、データベースは、すべてのBCがまだ同じ世界に住んでいることを確認します...

アドバイスが必要なので、後で維持するのが非常に難しいものを作ってしまうことはありません。

私の現在のプロジェクト (e コマース Web サイト) では、チェックアウト プロセスでの請求、配送、支払いなど、さまざまな境界コンテキストがあります。

これに加えて、顧客が何を購入するかによって、チェックアウトのプロセスが異なります。そのため、彼女のカートの内容によっては、チェックアウト プロセスのステップ数が異なる可能性があります。または、特定の情報を尋ねることはありません。

では、異なる種類のチェックアウト プロセスごとに異なる境界付けられたコンテキストを作成する必要がありますか?

たとえば、Order 集計ルートは、チェックアウト プロセス EticketsOrder によって異なります (このコンテキストでは、配送先住所は必要ないため、ユーザーには尋ねません)。

ClothingOrder (このコンテキストでは、配送先住所が必要であり、これを取得するためのチェックアウト プロセスに追加の手順があります)

この分離は、2 つの異なるドメイン エンティティが類似のプロパティを持っているとしても作成されることを意味します。

この種の問題をモデル化する最良の方法は何ですか? コンテキスト境界を見つける方法は?

Generic Context を使用した UnitOfWork があります。構造マップを使用して使用する具体的なコンテキストをリポジトリに決定させるにはどうすればよいですか?

ありがとう、

ダグ

We try to follow SOA and DDD principles in our project. We use NServicebus as messaging bus. So far we have 20+ services.

How do you guys set up monitoring (i'm not talking about technical monitoring - like is service "xyz" reachable - is the hard disk full) ?

For example

If an Order is placed and the shipping is done 5 days later but it should have been executed after 1 day ... that's an error condition.

Or another example: The shipping is done. Now we send an electronic invoice to our customer. We must archive that invoice and talk asynchronously with a third party (archiving provider) to retrieve our invoice. If that invoice is not retrieved after 5 days ... that's an error condition.

I have problems when defining HOW to model criterias on what is an error and WHERE to put these criterias.

WHERE ...

... do you set up Monitoring rules ?

Are monitoring rules part of your bounded context ? I think yes.
Are monitoring rules directly related to an entity ? I think no.
Are monitoring rules directly related to an aggregate ? I think no.

Monitoring rules are like Domain-Services that span multiple aggregates but as opposed to domain services can also span multiple bounded contexts.

Who is reponsible ?

HOW ...

... do you set up Monitoring rules in code ?

If you want to do it right its a really great deal of effort. Otherwise you could do it really cheap (make some queries here and there) but thats against SOA (the major part i'm concerned about)

Please guide me to a clear and easy to implement solution.

I'm also really excited to learn how you set this up.

質問のコンテキスト

そこで、アプリケーションを境界付けられたコンテキスト (Eric Evans の「ドメイン駆動設計」) に編成しました。境界付けられたコンテキストの 1 つが「ゲームプレイ コンテキスト」です。たとえば、インターフェイスが含まれていますGamer

Gamerの状態をデータベースに永続化できる実装もあります。

はるか遠く、「アカウント コンテキスト」と呼ばれる別の境界付けられたコンテキスト内に、アプリケーションのユーザーを処理するクラスとインターフェイスがあります。たとえば、 というインターフェースがありますAccount。

したがって、ユーザー /Accountはサインアップするかどうかを指定できます。任意Accountの に対して、対応する が存在しGamerます。

チャレンジ

私にはビジネスルールがあります。 Account

たとえば、これは、サインアップしていない一部Accountの JpaGamerインスタンスがフィールドにデータを書き込めないことを意味しsomeSensitiveDataます。JpaGamerこれは「未登録JpaGamer」であると非公式に言うことができます。

アカウント関連のロジックをゲームプレイ関連にハードコードしたくはありません (逆も同様です)。

境界付けられたコンテキストを他の境界付けられたコンテキストの概念で汚染することなく、Java でそのようなビジネス ルールを実装するにはどうすればよいでしょうか?

ビジネスルールを満たすために、「未登録」があるときはいつでもJpaGamer、それを でラップするという考えJpaGamerがありSparsePersistingGamerます。は、を改ざんする可能性のあるメソッドをSparsePersistingJpaGamer基になるメソッドに転送しません。 しかし今、私はその方法に問題があります。の場合、 JPA からすべてのゲーマーのフレンドを遅延ロードし、(およびその他の) ビジネス ルールを認識しないプレーンな s のセットを返します。JpaGamersomeSensitiveData
someGamer.getFriends()SparsePersistingGamerJpaGamersomeSensitiveDataJpaGamer

類似または関連する状況に対処するために、どの戦略を適用しますか?

私のアプリケーション内の「境界付けられたコンテキスト」(Eric Evan のドメイン駆動型設計) の大規模なリファクタリングと再構築により、その境界付けられたコンテキストの公開されたインターフェイスとそのメソッドのいくつかは、名前付けとセマンティクスが変更されました (ここで公開されたインターフェイスは、このインターフェイスがから呼び出されることを意味します)別の境界付けられたコンテキスト)。

私は現在、この更新された境界コンテキストを実装する過程にあり、変更されたインターフェースのパッケージ名を決定する必要があります。

• 旧姓のままでいいの？my.company.old.package.name
• バージョン番号を追加する必要がありますか?my.company.old.package.name.2
• ?

私の特定のケースでは、更新された境界コンテキストが自分のアプリケーション内でのみ使用され、他のすべてのクライアント境界コンテキストはほとんどないため、これらのクライアント境界コンテキストを変更して、新しい名前とセマンティクスに適応させることもできます。

おそらく、一般的に、パッケージ名を決定するのに役立つ基準/メトリック/経験則/ベストプラクティスがあります。あなたのものは何ですか？

私は、まったく新しいイントラネットプロジェクトのインフラストラクチャを作成し、ほぼすべてのベストプラクティスに従おうとしました。また、私も言及したいのですが、ゼロからアーキテクチャを作成するのはこれが初めてです。

現在、私のインフラストラクチャの最初のバージョンは準備ができており、正常に機能しています。しかし、次のバージョンで制限付きコンテキスト構造を実装したいと思います。

以下、現状を説明してみました。

DbCore：データ操作を担当します。EntityFramework5コードが最初に使用されました。DbContextクラスは1つだけで、すべてのDbSetが定義されています。また、GenericRepositoryパターンとUnit of Workパターンは、次のインターフェイスに基づいて実装されています。

IGenericRepository

IUnitOfWork

モデル： DbCoreおよびEntity Framework ドメインの責任ある格納エンティティモデル：ビジネスロジックレイヤーを表すと、Modelsプロジェクトに格納されたエンティティオブジェクトのDTOも格納されます。現在、次のインターフェイスIServiceを実装するServiceクラスに格納されているビジネスロジック

このサービスクラスは、ctorパラメーターを介してUnitOfWorkを取得し、操作に使用します。また、エンティティオブジェクトをDTOに、またはその逆に変換するためにAutomapperが実装されました。今後、エンティティモデルに関心がなくなったすべての上位レイヤーは、DTOのみを使用します。したがって、ほぼすべてのプロジェクト（apiおよびwebを含む）がこのプロジェクトを参照します。

共通：ロギングなどの一般的に使用されるライブラリを保存する責任があります。

WebCore： APIやMVCなどのWebベースのプロジェクトで一般的に使用されるライブラリを保存する責任があります。また、MVCベースのプロジェクト用の拡張機能、ハンドラー、フィルターが含まれています。

Api： ASP.Net MVCWebAPIプロジェクトはサービスレイヤーを表します。ドメイン層を消費し、クライアントにサービスを提供します。コントローラーは、ctorパラメーターとしてIServiceインターフェースを取得し、それを使用してドメインレイヤーを介してデータレイヤーにアクセスします。

Web： ASP.Net MVC 4ベースのWebプロジェクトで、ユーザーとの対話を担当します。データにアクセスするためにApiメソッドを使用します。すべてのコントローラーは、HttpClientを介してAPIを接続するIConsumeRepositoryという名前のインターフェイスを取得します。

Autofacは、すべてのプロジェクトのIoCとDIを担当します。

今のところ、これは私の現在のインフラストラクチャです。評価する必要があるすべてを説明したと思います。

今、私は次のことを理解しようとしています、

質問1：私が使用した方法に影響を与えてはならないものはありますか？

質問2：境界コンテキストを実装するための最良のアプローチは何ですか？最近、Julie Lermanのビデオを見て、たくさんのサンプルプロジェクトをレビューしました。DbContextからBCを派生させるのを見た一般的なこと。しかし、私は確信が持てませんでした。BCはDbCore（データアクセス）層ではなくドメイン（ビジネスロジック）層にあるべきだと思っていたからです。

質問3：前述したように、私のApiプロジェクトとWebプロジェクトはDTOを使用しているため、両方ともドメインレイヤーを参照する必要があります。しかし、APIを使用してUIからビジネスレイヤーを分離し、エンティティ用にそれらを再度結合しているため、私はそれが好きではありませんでした。しかし、私はこれより良い方法を見つけることができませんでした。

これは長い質問になりましたが、より良いアーキテクチャを作成するためにあなたのアイデアを私と共有していただければ幸いです。

私はかなり大きなデータベースを持っており、約 80 個のテーブルがあります。そのため、1 つの大きな edmx ファイルに 80 個のテーブルすべてを含めるのではなく、テーブルを境界付けられたコンテキストに分割することにしました。

そのため、Sales、Customers などのコンテキストを制限しました。

Customers edmx ファイル内にメインの顧客テーブルがあります。ただし、Sales edmx コンテキストの顧客テーブルから、すべてではなく、1 つまたは 2 つのフィールド (たとえば、顧客オブジェクト/テーブル全体ではなく、顧客名のみが必要) にアクセスする必要もあります。

顧客テーブル全体を Sales edmx ファイルに追加する必要がありますか? このシナリオのベスト プラクティスは何ですか?