4

いくつかの概念を理解しようとしていて、理解できていない

Ports and Adapters アーキテクチャのユースケースは何ですか?

ユースケースの実装はどのようになりますか?

ユースケースの懸念事項とは何ですか?

インフラストラクチャまたはドメインのどこに収まるか、アプリケーションに入ると言われていますが、アプリケーションコアとアプリケーションサービスがあり、私の理解では異なりますか?

左側では、アダプターはポートに依存し、ユースケースを含むポートの具体的な実装が注入されます。こちら側では、ポートとその具体的な実装 (ユース ケース) の両方がアプリケーション内に属します。

https://herbertograca.com/2017/09/14/ports-adapters-architecture/#what-is-a-port

この引用は私を混乱させます...私が理解していることから、プライマリアダプターは、ビジネスロジックを要求するものであれば何でもかまいません (提供するものに関心があります) WebAPI、MVC、テスト、ConsoleApp.

左側では、アダプターはポートに依存し、ユースケースを含むポートの具体的な実装が注入されます。

だから私はそれがあなたのビジネスロジックが注入されていることを指していると思います。たとえば、WebApiControllerコンストラクター

こちら側では、ポートとその具体的な実装 (ユース ケース) の両方がアプリケーション内に属します。

だから何 ？これは誰ですか

応用

それは WebApi ですか？それともドメインですか？また、私が理解しているユースケースは、ビジネスロジックの実装であるため、たとえば、設計は次のようになりますか?

Client :
WebApiController(IMyBusinessServicePort service)

Infrastructure :
ImplementingPrimaryAdapter : IMyBusinessServicePort { }
ImplementingSecondaryAdapter : ILoggingPort { }

Domain :
ImplementMyBusinessLogicService : IMyBusinessLogicService

WebApiController は、私のドメインのものではなく、ImplementingPrimaryAdapter によって提供される実装を使用しますか? 理解できない

説明してください 。

4

3 に答える 3

0

コール スタック ベースのプログラミングを使用するか、アクター モデルなどを使用するかによって、実装にいくつかの違いがあります。

次に、DDD と CQRS の "C" 部分に最も近いケース、つまりシステムの状態を変更するケースについて説明します。「Q」の部分は、Hexagon 側から見るとより単純です。その複雑さは、主にアダプター側にあります。

私はヘキサゴンの核にボキャブラリーを入れています。これは DDD ユビキタス言語モデルにマップされ、不変のデータ構造で構成され、これらのデータ構造のビジネス不変条件が検証されます。

次に、意思決定のポイントがあります。決定を下すときは、単一​​責任の原則に従って、これだけを行う必要があります。外部呼び出し、IO などを行わないでください。したがって、決定を下すにはいくつかの情報が必要です。この情報が収集されると、Command オブジェクトでラップできます。それを意思決定者に渡します。意思決定者は、DDD 集計に大まかにマッピングします。次に、コマンドを承認し、Event または Changeset (EventSourcing を実行するかどうかに関係なく) を生成するか、拒否を生成します。外部呼び出しなし。つまり、Hexagon のポートは使用しません。

Hexagon の内部に残っているのは、外部データを収集し、意思決定者を呼び出して結果を処理するためのロジックです。このロジックは、単純な有限ステート マシンとしてモデル化し、単体テストを行うことができます。これは、私が Hexagon でユース ケースと呼んでいるものです。これは、ポートと意思決定者の間のデータ フローが調整される場所だからです。したがって、ユースケースはポートを使用します。

Hexagon のプライマリ ポートでビジネス リクエストを受信すると、ユース ケース インスタンスが作成されます。ユースケースの FSM とエグゼキュータがあり、実際にセカンダリ ポートを呼び出し、応答を受け取り、ユース ケース FSM を進めます。

ユース ケースの処理フローは、次の手順で構成できます。

  • 受信したビジネス リクエストの検証
  • 無効な場合 - エラーのある形式のビジネス レスポンス
  • 有効な場合 - セカンダリ ポートへのリクエストを準備する
  • 準備されたリクエストを送信する
  • セカンダリ ポートの応答を受信する
  • 失敗またはタイムアウトの場合 - エラーのある形式のビジネス応答
  • データが正常に収集されたら、意思決定者のためにコマンドを準備します
  • 意思決定者を呼び出して、イベント/変更セット/拒否を取り戻す
  • 拒否された場合 - ビジネス リクエストをエラー付きでフォーマットする
  • 受け入れられた場合 - 決定を実行するために、セカンダリ ポートに対する別の一連のリクエストを準備します: DB への永続化、MQ への送信、ロケットの発射など。
  • セカンダリ ポートによるリクエストの実行を待機する
  • 失敗した場合 - ビジネス レスポンスをエラー付きでフォーマットする
  • OK の場合 - ビジネス レスポンスを成功として書式設定する

そのため、ユースケースはアダプターの実装ではなくインターフェースに依存するため、確実にドメインに属します。また、ドメインのアプリケーション層を形成します。

ユースケースをコードの別のフラグメントに入れると便利です。これは、このコードを変更する理由が 1 つになるためです。つまり、ユースケースが変更された場合です。これは、意思決定ロジックやドメイン値検証ロジックとは異なります。

于 2018-09-14T18:48:41.823 に答える