banq
2012-09-01 09:33
2012-08-31 18:34 "@clonalman"的内容
领域上“需要记录船经过的港口”与技术上Event Sourcing,刚好重叠而已

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

很好,下面我谈一下从个体推演到普遍的论证过程,你看逻辑是否严谨:

1.DDD强调统一语言,所谓统一语言,也就是统一需求人员和技术人员的用语,不能各用一套自己的定义,这样就会鸡同鸭讲,需求和技术脱节,导致软件实现错误需求,或者无法跟随需求变化而变化,这类似一种电视游戏:拷贝不走样,几个人通过动作模仿传递一个成语,结果到最后一个人得出的结论完全相反,这是反映信息在传播中的失真。所以,建议统一语言,能够让大家用同一种描述方式来谈论问题。

2.什么是统一语言?

统一语言有不同流派,比如最早的SOA的服务概念也是一种统一语言,所以,我们做系统项目时,总是有服务类,而在现实中也存在各种从服务角度描述的需求,比如加油站加油服务等等。

服务这个统一语言,需求人员能够理解;技术人员也能够理解,不就是一个无状态的功能类嘛。

同样,EventSource提出事件和服务一样,也是一种统一语言,虽然案例中是以货运为案例,但是只要有服务的地方就有事件,为什么这么推理呢?

从本站以前一直讨论的四色原型也就是彩色UML,它认为需求世界分为四种颜色,就像我们认为颜色是由三原色组成一样,这四色有角色 活动 和事情和描述。

其中活动这一分类可以对应到服务或者事件,活动发生,也就是事件发生,角色可以认为和场景Context有关。

好,下面再看看其他流派,比如BDD行为驱动开发,其Given When Then模板实际也是一种统一语言,它认为任何用例需求可以用这种模板去分解。所以,统一语言实际是一种方法论。

再看看DCI,它认为领域模型总是在一定场景下扮演角色,实施一定的行为(或发生什么事情),普通平民(领域模型)充当恐怖分子角色,实施爆炸事件。

从列举法来看,由ES/彩色UML或DCI等等都不约而同谈到活动事件,我由此统一总结为:场景(角色) 事件和状态为一个万能模板,是一种统一语言。

3.统一语言是横跨业务领域和技术架构

由于业务领域和技术架构是天然两个世界,所以,从技术架构内部无论寻找什么超酷的技术都无法和业务领域无缝结合,反之,我们也不可只从某个具体业务领域内部找一个和技术架构无缝衔接。

只有寻找一种凌驾于业务领域和技术架构的,类似神仙姐姐的统一语言,通过这个神仙桥梁,搭建起业务领域和技术架构无缝结合。

那么是否有必要使用CQRS和ES呢?那看你们团队善于掌握哪种统一语言,如果都熟悉服务,那么SOA也许合适,但是它也有缺陷,忽视领域模型的地位了。

如果熟悉事件,当然ES和CQRS是选择,而且事件是围绕DDD实体的,这和DDD比较接近。

如果熟悉场景角色,DCI是一种选择,这也是围绕DDD实体的。

当然,我个人是推崇结合DDD+DCI+ES/CQRS,包括Jdonfamework也是这样,因为DCI和ES虽然正交,但是不矛盾,DDD的实体充当DCI的数据模型,DCI的Context是角色扮演场所,角色实施的行为是事件,事件由角色在一定场景下发出。

以上只是我个人见解,批评指正。

[该贴被banq于2012-09-01 09:37修改过]

clonalman
2012-09-01 10:49
不知道是不是我对DDD理解有差异,当用DDD进行建模的时候,我一判断的标准是这个模型是否准确的描述现实,因为模式只要能反映实际,并把这个信息传递给技术即可,既于在技术上如何实现,使用哪一种技术来实现都不应该是DDD的考虑的范围。

DDD的模型是一个需求与技术妥协的结果,我担心会背离实际业务模型,DDD提供了一个统一描述业务的模型,我不认为少了一个角色(技术上也许很难实现),但不会因此而影响到技术人员对业务的理解了

统一语言应该是统一“需求”、“技术”或其他人在描述业务上的差异,

判断统一语言好坏标准应该是有没有能力描述并真实反映各种各样的复杂业务,应该具有一定的强制性;

(上述标准DDD、DCI、SOA那个更有优势?)

我们可能对"统一语言"的理解并不完全"统一",也是所有理解差异的思想根源。

[该贴被clonalman于2012-09-01 12:22修改过]

banq
2012-09-01 14:14
2012-09-01 10:49 "@clonalman"的内容
我们可能对"统一语言"的理解并不完全"统一",也是所有理解差异的思想根源。 ...

可能是吧,求同存异吧。呵呵。

donglangjohn
2012-09-01 14:56
打扰两位了。

领域对象的动作会产生事件,请问

1.这个“产生”,怎么体现?

2.“事件”是“被”产生的,那么如何来“复原”这个“事实”呢?

目前个人观点:

1. “产生”么, 直接点, 由领域对象的行为来返回“事件”,向外宣称该动作的“结果”--》既“事件”。

2. “复原”,这个就不好办了,得看领域边界外的对象如何识别,能够认知哪种“事件”--被“复原”后的事件。

补充:“复原事件(事实)”,我理解为 针对某“某事件”的描述。毕竟 “动作”产生“事件”,“事件”是结果,“动作”已经over了。

如有打扰,抱歉了.

clonalman
2012-09-02 08:15
事件不一定返回,像上面"船运跟踪服务"一样,可支持化作为一个记录供查询之用即可,如果业务复杂,有其他模块也关心这个事件,可以订阅发布(比如,到港之前需要先检查通关手续是否完成).....

从技术角度,记录是可以还原的,但要把所有相关连的对象都返原(如果有财务方面过帐就更麻烦了),领域的角度,不是所有的动作都能"买到后悔要的",大部分情况都不能...

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