Spring Boot を使用してマイクロサービスを開発し、多くの混乱した状態を解消する必要がある永続オブジェクトを開発する必要があるため、 Spring State MachineとState の設計パターンを研究しており、そこからクリーンな設計ソリューションを探しています。混乱。DDD、状態の概念、状態マシンをチェックして、どれを適用するかを確認しました
いくつかの概念を実装する方法と、それらを接続する方法がわかりません。次の場合は、理解したいと思います。
- Spring State Machine は、遷移中のエンティティで機能しますか、それともグローバル アプリケーション状態レベルでのみ機能しますか?
- 複数のエンティティをそれぞれ独自の状態で管理するには、プロトタイプ スコープのコンポーネントとして作成する必要がありますか?
- State パターンと簡単に統合できますか、それとも一緒に使用すべきではありませんか?
- これを管理するには、ステートまたはステート マシンをエンティティに挿入する必要があります (実行可能であることはわかっていますが、 @Configurable と適切な AspectJ ウィービング構成を使用するという考えは好きではありません)。より複雑になる可能性があるという誰かの印象を共有します。
@Scope("prototype") - 代わりに、単一のエンティティが状態を変更するために、ドメイン サービスにエンティティごとに (つまり別のドメイン サービス) ステート マシンを委任することが可能である場合は? または、これは貧血ドメインのアンチパターンですが、もしそうなら、ステート マシンは DDD とどの程度うまく統合されますか?
- Spring State Machine を使用してやりたいことを実行できるようにする方法、それがどれほど軽量であるか、そしてそれがどれほど遅くメモリを消費するかについての例はありますか?
私はそれを得ました: - DDD は、単純なデータ オブジェクトよりも多くの機能を持つドメイン オブジェクトを望んでいます。これは、この非常に完全ですが、DDD に関する少し古い記事のようです- 状態パターンは、その特定のケースでコンテキスト要素がどのように動作するかをカプセル化する必要があります - 状態マシンは約ですある状態と別の状態の間の通過の管理をカプセル化する - それらが連携する必要がある場合、状態は特定のコマンドで次の状態を指示するのではなく、状態マシンのイベントを生成し、状態マシンが選択する (またはブロックする場合)失敗する Guard があります) 新しい状態 - どういうわけか、状態マシンによって新しい状態をコンテキストに設定する必要があります
通常、Context オブジェクトは State オブジェクトに直接委任する必要があります。しかし、ステート マシンがオブジェクトのステートの変更を決定するため、この場合、コンテキストは一種のプロキシ ステートに委任されるべきではないでしょうか? ステート マシンをエンティティまたはプロキシに注入する必要がありますか?
これらの質問のいくつかについて、考え、提案、部分的な回答をいただければ幸いです。
ところで私はただ