3

シナリオの分離された境界コンテキストの統合を理解しようとしています。

1 つのコンテキストがDocument Core Bounded Context (BC)であり、 Authorを持つDocument Entity を持っているとします。ユーザー、グループ、およびロールを独自のコンテキストに分離するDDDの実装ブックのように、 IdentityAccessContext BCを使用することは理にかなっています。

発生している問題は、たとえば 100 以上のドキュメントのリストをフェッチすることを検討する場合です。

ドキュメント コアBCには、ドキュメントの作成者をマークする独自のエンティティがあるとします。

public class Author
{
    long Id; // Same as UserId
    long Document;  
}

そして、アイデンティティBCには関連情報を持つユーザーがいます。

public class User
{
    long Id;
    string FullName;
}

List of Documentsを取得する場合、 IdentityAccess BCからの情報はどのように取得してDocument Authorに表示する必要がありますか (フルネームなど)?

いくつかの選択肢があるようです：

  1. おそらく、両方のテーブルからデータを取得する腐敗防止レイヤーでしょうか?
  2. 2 つの BCでユーザーの氏名を複製しますか?

#1 では 2 つの BC からデータを (あるレベルで) 結合する必要があり、#2 ではユーザー名を変更するときに複数の BC を更新する必要がある可能性があるため、どちらも適切ではありません。

これについて何ができるでしょうか？(問題がある場合は、C#、MVC、NHibernate を使用します) オブジェクトのリストを明確に取得し、後で作成者の名前や追加データなどを後で取得することは現実的ではありません。

ただし、 BC統合を見ると、本 RPC、ドメイン イベント、および RESTful サービス統合で言及されている 3 つのオプションを考えると、アプリケーションが MVC であるこの場合、少なくとも後者の 2 つは意味がなく、直接2 つの BC はクラス ライブラリとして使用され、どちらも同じデータベースを使用します。ユーザー情報の更新は、Identity BC のアプリケーション サービスを介して MVC から直接行うことができます。データベースと BC は必要に応じて変更できます。

4

2 に答える 2

1

あなたが興味を持っているかもしれないいくつかの解決策：

A. ドキュメントの境界付けられたコンテキストで冗長な属性を使用する。お気に入り

public class Author {
    long Id; // Same as UserId
    string fullname://redundant
    long Document;  
}

しかし、これは柔軟ではなく、クエリの要件が変わるとモデルを変更する必要があります。

B. ドメイン モデルはクエリが苦手です。CQRS に精通している場合は、別のクエリ コンポーネントを構築することをお勧めします。

于 2013-11-28T01:13:32.413 に答える