1

質問のコンテキスト

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

public interface Gamer {
    void setFriends(Set<Gamer> friends);
    Set<Gamer> getFriends();
    ....
}

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

@Entity
public class JpaGamer implements Gamer {
    private String someData;
    private String someSensitiveData;

    public setFriends (Set<Gamer> friends) {
        ...
    }

    ...
}

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

public interface Account{
    boolean isSignedUp();
    ....
}

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

チャレンジ

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

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

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

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

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

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

4

1 に答える 1

2

サインアップしていないアカウントに関連する機密データは決して保持しないでください。

Gamerこのルールは、エンティティがアカウントのステータスを知る必要があることを示唆しています。私はあなたのドメインに詳しくないので、境界についてコメントすることはできませんが、ゲーマーとアカウントという 2 つの異なる BC があると仮定しましょう。これは、何らかの同期が必要であることを示しています。アカウント BC からの情報をゲーマー BC に送信する必要があります。情報はさまざまな方法で渡すことができます。

1 つの方法は、イベント ドリブン アーキテクチャ (EDA) を使用して各ゲーマー エンティティのアカウント ステータスを非正規化することです。アカウントのステータスは、エンティティの動作に影響を与える適切な情報であるため、ゲーマー BC を汚染することはありません。アカウント BC がステータス変更に関するイベントを発行し、ゲーマー BC がそれらの変更をサブスクライブし、ゲーマー エンティティの非正規化データを更新するように、EDA を設定できます。ここでの利点は、2 つの BC が自律的であることです。ただし、考慮すべき要素は結果整合性です。アカウント BC の変更は、ゲーマー BC とトランザクション的に一貫性がありません。遅延はますます小さくできるため、これは多くの場合許容されます。

もう 1 つの方法は、アカウント ステータス データを、その情報を利用するゲーマー エンティティのすべての動作に提供することです。この情報は、ゲーマー エンティティに関連するユース ケースを実装するアプリケーション サービスによって取得されます。はGamerApplicationSerivceAccounts BC を呼び出します。このアプローチの利点は単純であることです。イベント処理をセットアップする必要はありません。マイナス面は、自律性の低下です。アカウント BC は、Gamerアカウント ステータス情報を必要とするユース ケースで運用する必要があります。

また、異なるエンティティ実装の使用を避け、エンティティ インターフェイスを避けることをお勧めします。これにより、不必要な複雑さが増し、動作についての推論がより困難になります。代わりに、すべてのドメイン ロジックをエンティティで明示的に表現し、アンビエント アプリケーション サービスまたはイベント ドリブンの非正規化によって必要なデータを提供します。

于 2013-01-12T19:41:51.300 に答える