問題タブ [hexagonal-architecture]

クリーン/六角形アーキテクチャ パラダイムを使用してアプリケーションを設計していますが、これについては初心者です。いくつか質問があります。

シナリオは次のとおりです。

• 「エンティティ」情報と関連する「ドキュメント」を提供する外部 SOAP サービスがあります。
• すべてのエンティティについて、アプリケーションは次のことを行う必要があります。
  • すべてのエンティティ ドキュメントを CMS に保存する (コンテンツといくつかのエンティティ属性)
  • 格納されたドキュメント参照を使用して DDBB にエンティティを格納する

Java のようなアプローチでの最初のソリューションを見てみましょう。

エンティティとドキュメント

ドメイン層での FRepositori の抽象化

ドメイン層での DocumentRepositori の抽象化

SOAP サービスのアプリケーション層での ExternalService 抽象化

アプリケーション層でのユースケースの実装

質問

1. ExternalService については、Entity と Document で抽象化を定義するのが正しいですか、それとも UseCase 実装がエンティティに変換する ValueObject を返す必要がありますか?
2. Document については、集約ルートとして設計し、Entity から Document オブジェクトの参照を排除する必要がありますか?

私は DDD と Hexagonal アーキテクチャを学んでいます。基本は理解できたと思います。ただし、解決方法がわからないことが 1 つあります。ユーザーにデータを表示するにはどうすればよいでしょうか。

たとえば、いくつかの機能を備えた Worker エンティティ (一部のメソッドによってエンティティが変更されます) と WorkerRepository を持つ単純なドメインを取得したので、Worker を永続化できます。ドメインを操作するためのいくつかのコマンドとコマンド バス (ワーカーの作成、作業時間の更新、変更の永続化など) を含むアプリケーション層と、WorkerRepository と GUI アプリケーションの実装を含むインフラストラクチャ層を取得しました。

このアプリケーションでは、すべてのワーカーにデータの一部を表示し、それらを変更できるようにしたいと考えています。データを表示するにはどうすればよいですか?

1. WorkerRepository の実装への参照を与えることができます。この方法では、コマンド バスをスキップして新しいワーカーをリポジトリに挿入できるため、これは良い解決策ではないと思います。コマンドバスを介してすべての変更が行われるようにします。
2. では、WorkerRepository を WorkerQueryRepository と WorkerCommandRepository に分割し (CQRS に従って)、WorkerQueryRepository のみを参照します。リポジトリは、それらを変更するメソッドを持つ Worker エンティティを返すため、これはまだ良い解決策ではありません。これらの変更はどのように永続化されますか?
3. 2 種類のリポジトリを作成する必要がありますか? 1 つはドメインとアプリケーション層で使用され、もう 1 つはデータを外部に提供するためだけに使用されます。2 つ目は、完全な Worker エンティティを返すのではなく、GUI が必要とするデータのみを含む WorkerDTO のみを返します。このように、GUI でワーカーを変更する方法は他になく、コマンド バスを使用するだけです。

3番目のアプローチは正しい方法ですか？または、変更がコマンドバスを通過する必要があることを強制するのは間違っていますか?

まったく新しいdomain model(およびBounded Context) ' Appointment' 用の新しいアプリケーションを作成しています。CQS新しいドメインには、Hexagonal Architecture(ポートとアダプターを使用して) を組み合わせることにしました。

パッケージ構造は主に次​​のようになります。

私の質問:

1. このパッケージ構造は、私たちが達成しようとしていることに問題ありませんか?

2. インターフェイスを介して他のドメインとの間のすべての通信を確認したいと考えていAppointmentScheduleFacadeます。クロスドメイン通信は、分散されていないため、単純なメソッド呼び出し (RPC または REST なし) として存在します。

   ファサードは主に次のものに委任します。

   • AppointmentScheduleApplicationService.javaモデル修正用
   • AppointmentScheduleQueryService.java他のドメインにデータを渡すため。

この設定は大丈夫ですか？または、他のドメインがApplicationandに直接対応する必要がありQueryServiceますか?

の例を通して六角形のアーキテクチャを理解しようとしていRepositoryます。このセットアップでは、次のレイヤーがあります: フレームワーク (インフラストラクチャ) -> アプリケーション -> ドメイン。

私はドメイン部分に持っています.aを介して重複がないかどうかUserを検証したいとしましょう. この情報を取得するには、どこかからこの情報が必要です。ドメインレイヤーにインターフェースを再度追加しました。このようにして、上のレイヤーで解決できます。UserDuplicateUsernameValidatorUserRepository

これは私にとってトリッキーになる部分です。のロジックを実装したいのですがUserRepository、これをアプリケーション層に実装するのは意味がありません。なぜなら、永続化コンテキストはインフラストラクチャ層 (JdbcUserRepositoryまたは などJpaUserRepository) にあるからです。しかし、六角形の構造を正しく理解していればUserRepository、インフラストラクチャ レイヤーにインターフェイスを直接実装することはできません。これは、インフラストラクチャ レイヤーがドメイン レイヤーを認識する必要がないためです。

私は何が欠けていますか？