最終的なユーザー登録の一貫性

Question

私たちのプロジェクトはDDDを使用して開発されました。ユーザーIDの確認、トークンの発行と検証に使用される単一のマイクロサービスにユーザーIDを移動することにしました。

アカウントとユーザーは、ユーザーとアカウントの詳細を処理する問題を解決している別のマイクロサービスに配置されているため、最終的な一貫性と呼ばれる挑戦に遭遇しました。

私たちの質問は、まずアカウントとユーザーのマイクロサービスでアカウント/ユーザーを作成してから、ユーザーIDのマイクロサービスにイベントを公開するか、またはその逆にする必要があります。

最初のケースでは、アカウントとユーザーの基本情報をすぐに利用できるようになりますが、最終的な一貫性の遅延のためにトークンを提供できないため、ユーザーはログインできません。

2番目のケースでは、ユーザーはログインできましたが、彼が自分のアカウントにログインすると、最終的な一貫性の遅延のためにアカウント情報は利用できません。この場合、最終的な一貫性が満たされたときに確認メールを送信するという回避策があるため、ユーザーは登録とログインを確認できます。

私はフィードバックをお聞きしたいと思いますが、この場合はもっと理にかなっていますが、この時点では何の問題もありませんか？

Answer 1

最終的な一貫性の遅延は必要ありません。 regiatrationCompletedイベントは、すべてのパーツが完了した後にのみ発生する必要があります。このイベントは、あなたのインターフェースが応答するもので、ウェルカム電子メールとそのようなアクションを引き起こします。

異なるマイクロサービスでは、イベントを並行して処理できるため、このregistrationCompletedイベントの発生時間は非常に短いはずです。

セキュリティ上の問題（特定の権利を持つアカウントやロックされているアカウントなど）が発生する可能性があるため、アカウント情報なしでログインすることはすべてのオプションの中で最悪です。

また、マイクロサービスは可能な限り小さく、小さくはないことにも注意してください。あなたは合理的に分割ケースを処理することはできませんし、あなたは小さすぎた。

Answer 2

ハンマーがあれば、すべてが爪のように見えます。それはあなたがそれを保証しない問題に壮大なアイデアを適用するには余りにも苦労しているように見えます。

DDDを使用して問題に近づくときは、戦略的なDDD、つまり設計部分を考えることが重要です。バウンド・コンテキストは、特定の言語が存在し、特定のビジネス機能にリンクされた実装として明示されます。

各BCを見て、どのようなアーキテクチャがそのコンテキストに適しているかを判断するのはあなたの仕事です。システム全体は、私は同じ実装に従わなければならないと言ってはいけません。 account \ loginの作成には本当にマイクロサービスが必要ですか？あなたが導入した最終的な一貫性の問題をなくして、CRUDのような実装を取り除くことができるように思えます。

簡単にしてください。