在我们的事务管理系统中有一个事件的核心概念。
事件是按业务规则定义的目标实体在其生命周期中的当前状态的连续、明确的数字编码。事件累积事件的整个处理历史。对于每种目标类型，在其生命周期中都有数十种可能的事件。
Events 表是架构中迄今为止最大的表，每年的频率达到数千万行。
事件是控制 UI 工作流程、集成和批处理流程的最核心概念。这些事件的有据可查的数值值编码主要部分的业务规则基于复杂的方程式和顺序比较 这些数值及其组合以得出下一个状态转换并执行验证。就像事件数字形成了它自己的 DSL。
我对这种设计选择及其背后的规划过程着迷。如果我要设计一个复杂的企业系统，我最好的资源是什么来学习建模和恰当地应用这些中心设计选择？这就是 DDD 技术的用武之地吗？
【问题讨论】：
标签： oop design-patterns database-design architecture domain-driven-design
托马斯。它听起来很迷人，很像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/
【讨论】：