1

最初は次のようなモデルがあります

class Person extends EntityBase<Person, PersonNumber>{
 private PersonNumber personNumber;
 private String name;
 private Contact contact;
 private String educationLevel;
}
class Contact extends ValueObjectBase<Contact> {
  private String phone;
  private String address;
  private String contactPerson;
}

ただし、別のシステム名「System DC」と統合する必要があります。元のpersonテーブルが分解され、personNumber、name、phone、address列が「SystemDC」に移動しました。また、「SystemDC」は、クエリ用にデータベースビュー「DC_PersonView」を提供します。人を作成する必要がある場合は、「SystemDC」からWebサービスを呼び出す必要があります。

したがって、personDTOを次のように定義します

 class PersonDTO{
 private PersonNumber personNumber;
 private String name;
 private String phone;
 private String address;
 }

プラン1：

  1. 人をIPersonインターフェースにリファクタリングする

  2. PersonWrapeクラスを定義する

    class PersonWrape implements IPerson {
 private Person person;
 private PersonDTO personDTO;
}

  3. PersonWrapeリポジトリ内

    void SavePerson(IPerson person) {
  systemDC.saveWebservice(person.getPersonDTO);
  personRepository.save(person);// map the column not in systemDC like  educationLevel to our person table.
  }

プラン2：personRepositoryのみを変更します。

    void SavePerson(IPerson person) {
      PersonDTO personDTO = PersonDTO.fromEntiry(person);
      systemDC.saveWebservice(personDTO);
      personRepository.save(person);// map the column not in systemDC like  educationLevel
      }

しかし、クエリ担当者は問題になります。

この状況でどのようにモデル化しますか？いくつか提案をお願いします。

4

2 に答える 2

1

DTOを使用し、SOAを使用するときにドメインモーダルを公開しないのは素晴らしいことです。それ以外のものは、最終的には混乱します（クライアントアプリケーションでドメインモデルを操作しようとします）。

ただし、問題は、ドメインモデルをCRUDSOAサービスとして公開しようとすることです。SOAサービスに任意のエンティティのフィールドを変更させることはできません。ドメインモデルと、その中で定義したメソッドとサービスに従う必要があります。

例えば。User呼び出されるクラスにメソッドがある場合は、と呼ばれるものではなく、とCalculateAge呼ばれるSOAメソッドを作成します。CalculateUserAgeUpdateUser

于 2012-12-04T07:29:40.297 に答える
0

2つの境界コンテキスト（BC）間の統合シナリオがあるようです。これらのシナリオでは、エンティティの変更がどのように伝播されるかを決定できる関係BCを識別することがしばしば可能です。

あなたのユースケースでは、人の概念が1つあるように見えますが（各人はBC間で共有される単一のIDを持っています）、2つの異なるBCがあり、各BCには異なる人のデータが含まれて管理されています。次に、説明する保存操作は、実際には各BCに1つずつ、合計2つの保存操作です。各BCは、関心のある情報を保存します。両方のBCの個人情報を受け入れるUIフォームなどのユースケースがある場合、そのユースケースは、saveコマンドを両方のBCに明示的に送信する必要があります。あなたのプラン2はこのアプローチに最も近いですが、私はそのコードをリポジトリに配置しません。代わりに、プレゼンテーション層またはアプリケーション層から直接2つの異なるサービスを呼び出します。

また、元のBC（これをAと呼びましょう）とシステムDCの間に何らかのダウンストリーム関係があるかどうかも考慮することができます。たとえば、DCが個人データのAのダウンストリームである場合、保存中に両方のサービスを明示的に呼び出す代わりに、イベント駆動型のアプローチを実装できます。このアプローチでは、Aは個人データの変更に関するイベントを公開し、AとDCの間の統合ポイントはそれらのイベントをサブスクライブし、 DCで適切な変更を行います。このアプローチは通常、結果整合性があることに注意してください。全体として、イベント駆動型のアプローチはより複雑ですが、より柔軟でもあります。

于 2012-12-06T17:31:11.997 に答える