在我们的事件管理系统中，有一个事件的中心概念。
事件是顺序的，明确的数字，用于编码目标实体在其生命周期中的当前状态（由业务规则定义）。事件累积了事件的整个处理历史。对于每种目标类型，生命周期中都有数十种可能的事件。
事件表是迄今为止架构中最大的表，每年达到数千万行的频率。
事件是控制UI工作流，集成和批处理流程的最核心概念。这些事件的有据可查的数字值基于复杂的方程和顺序比较编码这些数值及其组合>>即可得出下一个状态转换并执行验证。就像事件数字形成了自己的DSL一样。
这种设计选择及其背后的规划过程使我着迷。如果我要设计一个复杂的企业系统，那么我最好的资源是什么，以学习适当地建模和应用这些中心设计选择？这是DDD技术出现的地方吗？
答案 0 :(得分：1)
托马斯。听起来确实令人着迷，并且非常像Event Sourcing approach。 当然，我可能会错认为它是事件源，但是我将简要介绍一下这一概念。
事件来源很简单： “确保在事件对象中捕获对应用程序状态的每次更改，并确保这些事件对象本身按照与应用程序状态本身相同的生命周期被应用的顺序存储。”
事件来源与CQRS体系结构模式一起使用效果最佳。 格雷格·扬（Greg Young）可能是这些概念的最权威来源，因为他创造了here is one if his presentations。 这是马丁·福勒（Martin Fowler）在谈论The Many Meanings of Event-Driven Architecture
在“有据可查的数值”上，这可能是一个可用性组织-如果它们是通过算法计算的并且非常易于阅读，我将着迷。你可以发表一个例子吗？
有关事件源和CQRS的更多资源： https://medium.com/@hugo.oliveira.rocha/what-they-dont-tell-you-about-event-sourcing-6afc23c69e9a https://www.confluent.io/blog/event-sourcing-cqrs-stream-processing-apache-kafka-whats-connection/