此图是否遵循微服务、带有事件源的 DDD
Does this diagram follows Microservices, DDD with Event sourcing
- 事件溯源是否应该在流程的最后，是否应该有事件处理程序？
- 在跟踪事件源时，我知道我们可以随时从事件中获取应用程序状态，但我们是否也应该将该状态保存在数据库中？
您似乎想使用 CQRS + 事件溯源模式。
这里有一些例子：
- https://dzone.com/articles/microservices-with-cqrs-and-event-sourcing
- https://danielwhittaker.me/2020/02/20/cqrs-step-step-guide-flow-typical-application/
根据上面的链接，您可以修复您的体系结构，我认为这回答了第一个问题。
关于第二个问题，你应该有一个外部事件存储。
这两种模式在 book 中有很好的描述。
- 事件在域逻辑执行后发出（在 entity/domain 对象上执行了一些操作）。首先，事件保存在商店中，然后发布到总线，其他消费者（微服务、图表中的事件处理程序）可以订阅它。事件的持久化和发布应该像事务一样。
- 每次需要对域对象执行新操作时，整个事件集都会从该实体的事件存储中读取。一些实体可能有很多事件，为了优化性能，使用了所谓的 State Snapshots。基本上它是 X 事件后域对象的状态。可以每隔 X 个事件创建快照。它们单独存储在事件存储中，通常事件源库允许配置快照。但这只是为了性能目的。
我已经快速创建了图表以显示通常发生在 命令处理程序
中
- 事件溯源是否应该在流程的最后，是否应该有事件处理程序？
- 在跟踪事件源时，我知道我们可以随时从事件中获取应用程序状态，但我们是否也应该将该状态保存在数据库中？
您似乎想使用 CQRS + 事件溯源模式。
这里有一些例子：
- https://dzone.com/articles/microservices-with-cqrs-and-event-sourcing
- https://danielwhittaker.me/2020/02/20/cqrs-step-step-guide-flow-typical-application/
根据上面的链接，您可以修复您的体系结构，我认为这回答了第一个问题。
关于第二个问题，你应该有一个外部事件存储。
这两种模式在 book 中有很好的描述。
- 事件在域逻辑执行后发出（在 entity/domain 对象上执行了一些操作）。首先，事件保存在商店中，然后发布到总线，其他消费者（微服务、图表中的事件处理程序）可以订阅它。事件的持久化和发布应该像事务一样。
- 每次需要对域对象执行新操作时，整个事件集都会从该实体的事件存储中读取。一些实体可能有很多事件，为了优化性能，使用了所谓的 State Snapshots。基本上它是 X 事件后域对象的状态。可以每隔 X 个事件创建快照。它们单独存储在事件存储中，通常事件源库允许配置快照。但这只是为了性能目的。
我已经快速创建了图表以显示通常发生在 命令处理程序
中