clonalman
2012-08-31 11:31
“Mixin”在代码阅读上肯定是有障碍的,但它脚踏实地的解决方法,

一个对象属性方法在运行时再做Mixin,只是技术层面解决方案,

在领域层很也是难理解的,负影响也不小

[该贴被clonalman于2012-08-31 11:47修改过]

[该贴被clonalman于2012-08-31 11:57修改过]

banq
2012-08-31 11:57
2012-08-31 11:31 "@clonalman"的内容
在领域层很也是难理解的,负影响也不小 ...

嗯,那么我们看看scala,一般使用Scala的Actor模型来实现实体,Actor与外界交互都是消息,类似事件,这也是来自ERlang的并发模型,但是需要实体extends继承一下Actor(这与我们引入角色字段类似)。

所以,是否可以得出,领域和架构因为本来是正交的两件事,要将它们完美交合在一起,焊点总会看到? 呵呵。

clonalman
2012-08-31 12:07
主要是做实践的,理论上也没太多时间考虑,

Scala这个体系不是很了解(没时间研究)。:(

(实体直接继承Actor这个不好看吧,现在不都强调Pure Object)

领域与架构要找到一个结合点的话,

Bounded Context或Repository应该是再合适不过的了,用它来屏蔽技术细节

[该贴被clonalman于2012-08-31 12:32修改过]

banq
2012-08-31 14:25
Bounded Context是一个好的角度,不知你有无这方面实践分享一下。

再回到CQRS应用场景,CQRS和Event Source是密切相关的,ES属于CQRS中的Command部分,MartinFowler的ES文章谈到,将导致状态变化的所有事件提取出来。

比如我们原来没有在业务上引入考虑事件这个角度:

上面是典型的SSH或javaEE实现的方式,一个服务一个实体,而引入事件之后,如下图:

那么正如大部分系统都可以引入服务这个概念,“服务”这个概念既是业务也是技术概念,成为业务和技术架构的桥梁,谈到服务,业务人员知道它在业务上代表什么,技术人员知道如何实现它。

而“事件”也是一种和“服务”类似的介于技术和业务之间桥梁的术语,通过引入事件,应该不会对业务领域包括实体有伤害作用,也不会感觉它是天外来客或神仙姐姐,否则服务这个概念也应该是了。

不知上面观点是否认可?呵呵。

相关讨论:

业务建模: CQRS是鸡肋?

数据Data 上下文Context 交互Interaction(DCI):面向对象范式的演进

[该贴被banq于2012-08-31 16:07修改过]

clonalman
2012-08-31 18:34
完全同意,领域内的任何对象都可以是技术概念,而技术的概念不一定是领域的概念!

领域上“需要记录船经过的港口”与技术上Event Sourcing,刚好重叠而已

如果领域需求根本不许要记录船经过的港口,ShippingEvent根本就没有必要,

也没有必要使用CQRS,Event Shourcing(个人观点)

猜你喜欢
9Go 上一页 1 2 3 4 5 6 ... 9 下一页