私はユーザー管理Microservice（MS）を実装する過程にあり、自分が行っていることが大丈夫かどうかを調べたいと思っていました。ユーザーはUIから作成され、UIと相互作用します。 APIはユーザ管理MSにRPC呼び出しを行い、CreateUserCommandをInMemバスにパブリッシュします。その後、消費者はDBにユーザを作成してコマンドを処理しますが、Auth0に登録されているこのユーザも必要です。加入者が選択するために、永続的なキューに別のコマンドを送信することになりますそのユーザーをAuth0で登録する（永続的なキューがAuth0に届かない場合）。完了したら、UserCreatedEventを公開できますか？Auth0との統合
これについてのお手伝いがあれば幸いです。
2つの境界付きコンテキスト：User managementとAuthenticationがあります。
User management BCは、ユーザーの生存（作成、変異、削除）を処理します。 Authentication BCは、ユーザーがシステム内で自分自身をどのように識別しているかを扱います。
したがって、システムで自分自身を識別する可能性がある場合でも、ユーザーは存在する可能性があります。
ユーザー管理BCがCreateUserCommandを処理した直後に、AUserWasCreatedEventを発行する必要があります。この時点でユーザーが生まれたためです。それはIDを持っています、それをUserIDという名前にしましょう。
はその後、このユーザーは、自分自身を識別するために、平均値を必要としSaga（またはProcess managerまたはあなたはそれを呼び出すために好きな）イベントをキャッチし、それがAuth0のAPIを呼び出すことにより、Authentication BCに送信されることをCreateAuth0UserCommandを作成します。 APIは、おそらくtokenを含むいくつかのデータで応答します。そのトークンはAuthentication BCによって処理され、UserIDに関連付けられています。
私はAuth0でユーザーを登録したいので、私のデータベースのユーザーとAuth0ユーザーIDを結びつけることができます（独自のアプリケーションでuserIDが生成されています） 。したがって、ログインに成功するとトークンが付与されると（トークンにはAuth0のuserIDが含まれています）、そのユーザーのために自分のアプリで生成された関連するuserIDを見つけて、残りのリクエストに対して代わりに使用したいと思います。私のデータベースのユーザーにリンクすることができます。私のアプリのより複雑な動作からAuth0を切り離そうとしており、認証にAuth0を使用しています。これは意味がありますか？ – CraigM
Decoupleは非常に良いです、あなたも概念をデカップリングする必要があります。認証はユーザーを識別するだけです。ユーザーが特定されると、そのユーザーは承認される必要があります。その後、ビジネスロジック、コアドメイン、主な焦点だけです。 –
ユーザが作成され、auth0が失敗した場合は、ユーザの削除などの補償操作を行い、管理者に通知するか、または無視するだけです。これは複雑さが増したように見えますが、デカップリングには必要です。 –
DDDに従っていますか？ （*ほとんどの質問に） –
また、 'Auth0'は人間からの手動入力が必要ですよね？ –
はい、DDDに続きます。いいえ、auth0はユーザーを作成するための残りのAPIを提供し、Auth0と対話するために使用します。 – CraigM