0

次の状況を考えてみましょう: エンティティ A に更新要求があり、サブエンティティ AB を作成するために、A に多くの B が存在する可能性があり、各 B には一意の電子メール アドレスがあります。エンティティ A は共有エンティティであり、同じ要求が複数のサーバーで並行して発生する可能性があります (スケーラブルなマイクロサービス)。

AB を作成するには、B が A のサブ エンティティとして存在していないことを確認する必要があります (B の電子メール アドレスによる)。

この更新要求を処理するサービスは、更新を安全にするために、(一意の ID によって) A をロックする必要があります。

私の質問は、技術的なものよりも概念的なものです。

  1. この場合、リソース A をロックすることは、この更新タスクのビジネス ロジックの一部ですか?

  2. 検証と更新の手順を処理するミドルウェアとは別のミドルウェアにリソース ロックを配置することを検討しますか? (もう 1 つのオプションは、ロックをビジネス ロジックの一部として扱い、ビジネス ロジックを担当するミドルウェアに直接配置することです。)

4

2 に答える 2

1

競合の問題に対して選択したソリューションの技術的な実装は明らかにビジネス ロジックではありませんが、適切なソリューションを選択するにはビジネスの知識が必要です。

これが意味することは、同時実行シナリオでデータの整合性を保護するための適切なアプローチを決定するには、ビジネスがどのように機能するかを理解する必要があるということです。同時実行の競合はどのくらいの頻度で発生しますか? 競合は自動的に解決できますか? 何が競合する必要がありますか？それだけでなく、企業は強い整合性よりも結果整合性を受け入れる可能性が非常に高いです。

つまり、同時実行シナリオでデータの整合性を保護するために導入されたメカニズムは、ドメインの一部であってはなりません。これらはおそらくアプリケーション サービス レイヤーまたはインフラストラクチャ レイヤーのいずれかに配置されますが、ビジネスの専門家は、同時実行の競合をどのように解決し、それがビジネスにどのように影響するかについての議論に参加する必要があります。

于 2016-11-22T21:56:26.767 に答える