DDD 和依賴注入上下文中實體的狀態機？

Question

我一直在研究Spring 狀態機和狀態設計模式，因為我必須使用 Spring Boot 開發微服務和持久化對象，其中有很多需要清理的混亂狀態，我正在尋找一個干凈的設計解決方案混亂。 我檢查了 DDD、狀態概念和狀態機，看看要應用哪些

我不確定如何實現一些概念，以及如何連接它們。 我想了解是否：

1. Spring State Machine 可以在轉換期間處理實體，還是只能在全局應用程序狀態級別上工作？
2. 要管理多個實體，每個實體都處於自己的狀態，是否必須將其創建為原型范圍組件？
3. 它是否容易與 State 模式集成，還是不應該一起使用？
4. 為了管理這個，我應該將狀態或狀態機注入實體（可行，我知道，但我不喜歡使用 @Configurable 和適當的 AspectJ 編織配置的想法）？ 我分享了某人的印象，它可能會使它變得更復雜，也許我將不得不使用@Scope("prototype")
5. 相反，是否可以讓域服務為單個實體委托每個實體的狀態機（所以另一個域服務）來改變狀態？ 或者這是貧血的域反模式，但如果是這樣，狀態機與 DDD 的集成度如何？
6. 有沒有關於 Spring State Machine 如何讓我做我想做的事情、它有多輕量級以及它有多慢和多內存消耗的例子？

我明白了： - DDD 想要具有更多功能的域對象，就像這篇關於 DDD 的非常完整但有點過時的文章中的簡單數據對象 - 狀態模式應該封裝上下文元素在這種特殊情況下應該如何表現 - 狀態機是關於封裝一個狀態和另一個狀態之間通道的管理 - 如果它們一起工作，狀態不應該決定哪個是特定命令的下一個狀態，而是為狀態機生成一個事件，狀態機將選擇（或阻止有失敗的守衛）新狀態 - 不知何故，新狀態必須由狀態機在上下文中設置

通常 Context 對象應該直接委托給 State 對象。 但是由於狀態機決定了對象狀態的變化，在這種情況下，上下文不應該委托給某種代理狀態嗎？ 應該將狀態機注入實體還是代理？

對其中一些問題的任何想法、建議，甚至部分答案都將不勝感激。

順便說一句，我只是

Answer 1

DDD 完全是為了保護業務邏輯，並確保它不會受到基礎設施的影響或耦合。 當您查看一個實體時，您應該直接了解它的功能以及它負責域的哪個部分。

對我來說，狀態機不是域的一部分。 它們是促進者和應用層的一部分，控制域中應該發生的事情。 再說一次，在抽象級別上真的很難回答，因為 DDD 就是在非常“真實”的級別上進行建模。

如果您可以用一個簡單的示例來解釋您要完成的工作，那么您也可以更輕松地編寫更具體的答案。