聚合与一致性和有界上下文
2013-01-21 08:32 "@banq"的内容如果在这里引入“事件”概念可能就很清晰了，实体 值对象 、服务 和事件，四个要素，这样在领域层，为实体服务的函数就不叫领域服务，而称为领域事件，实体通过发出各种事件调度技术架构为其服务，而将领域服务真正落实为开放给应用层的接口。 ...
DDD创始人Eric Evans最近发表了一篇文章：
[PDF]在聚合根实现CAP定理 Acknowledging CAP at the Root -‐-‐ in the Domain Model
Eric Evans在文中阐述了聚合体内部 聚合体之间以及领域事件Domain event和有界上下文bounded context等概念。
CAP定理主要突出最终一致性，Eric Evans在这篇文章强调了聚合体内部必须保证高一致性，类似关系数据库更新那种，当然内存中聚合体可以采取线程锁等方式实现；而聚合体之间可以是一种弱一致性，也就是实现最终一致性，Eric还是使用了货运Cargo这个案例，在不同地方装卸时间不一样导致更新不一致。
如下图，聚合与一致性的关系：
[该贴被banq于2013-01-25 10:33修改过]
Eric evans强调了聚合体之间只能通过聚合根进行引用，而不能对聚合体内部元素进行引用，这样保证聚合边界的清晰。
聚合的定义：正如我们之前在DDD案例:网上商店讨论一样，聚合表达的是一种逻辑上的紧密联系结构，注意，还有这些逻辑结构的更新，如果说关系数据表通过外键等关系也能表达逻辑上的紧密联系，那么聚合与关系数据的区别是有更新动作，当然，关系数据表的更新是通过SQL+记录锁来实现，而聚合的更新通过编程语言如Java的锁等机制保证。
领域事件domain event代表一种对领域层中状态进行改变的发生事件或动作。这个在DDD大型实现我们已经讨论，如果不引入领域事件，会发生楼主在领域中引入领域服务的尴尬之处。
有界的上下文是对模型进行断言验证的地方，能够进行断言的必然是函数接口，而领域服务肯定是一种无副作用的函数接口，实际上也就说明了，有界的上下文是对领域服务进行调用测试的客户端使用现场。
看来Evans对DDD的进一步解释和我们在Jdon讨论的方向基本一致，没有发生大的偏差。
使用我们在Jdon讨论总结的Jdon分析法，很容易将Eric Evans的聚合体 领域事件和上下文结合在一起，正是所谓动静结合，如下图：
这张图展示的一个聚合体示意，如果是多个聚合体，重复按照这种图辅助即可，纵坐标目标是得出聚合，从逻辑上的紧密联系入手，找出需求领域中那种隐式的规律旋律：静态结构；横坐标是从领域事件入手，从用户操作角度思考动作路线。
而下面这张图展示了聚合内部数据问题一致性：
实际上DDD实践过程也确实证明了为什么计算科学中最难的两件事是命名和缓存失效。
猜你喜欢