1

設計上の問題があり、助けを求めています。

「ユーザー」、「機関」というドメインエンティティがあるとします。

この「利用者」は、「会計や図書館」など、さまざまな「サービス」に登録することができます。「ServiceRegistration」の抽象クラスを作成し、「User」にはこれらのサービス登録のリストがあります。これらのサービスは、将来コンポーネントとしてプラグインされるモジュールに他なりません。ライブラリ コンポーネントが完成したら、システムにプラグインできます。Library コンポーネントには、"User" -> "ServiceRegistration" リストに格納される "LibraryServiceRegistration" クラスがあります。「ユーザー」はこの「LibraryServiceRegistration」を認識しないため、拡張可能になります。ライブラリコンポーネントは現在「User」を認識しているため、「LibraryServiceRegistration」情報を「User」に格納できます。

しかし、ここで、「ユーザー」と「機関」に適用可能な新しいコンポーネント「会計」を作成したとします。私の会計コンポーネントには、すべてのユーザーの "User" -> "ServiceRegistration" と "Institution" -> すべての機関の "ServiceRegistration" に "AccountingServiceRegistration" が格納されます。

「会計」コンポーネントを分離して、サービスを提供できるドメインエンティティにも構成できるようにしたいと考えています。したがって、現在、コードを変更することなく、将来「ユーザー」と「機関」にサービスを提供できます。

これは可能ですか？

4

1 に答える 1

0

したがって、システム内のコードの一部は、サービスとエンティティの両方について知る必要があることは明らかです。問題は、どのコードがそれを処理する必要があるかということです。

私が見るオプションは次のとおりです。

  • エンティティは、それが取ることができるサービスを定義します（投稿によると望ましくありません）
  • サービスは、サポートするエンティティを定義します (可能)
  • サービス登録クラスは、サポートするエンティティを定義します (これも良いかもしれません)
  • 新しいクラス (factory?) がマッチングを処理します (すでに factory を使用している場合は機能する可能性があります)。

すべてのドメイン エンティティが共通のインターフェイスを実装している場合、これらすべてが非常に簡単になります。

私の推奨事項は、サポートするエンティティをリストする基本サービスに抽象メソッドを用意することです。各サービスは、サポートするエンティティを宣言します。さらに、エンティティに対して新しい登録を作成する Service のどのメソッドでも、エンティティ タイプを検証できます。

これが役立つことを願っています

于 2013-09-12T16:36:31.820 に答える