如果领域需求根本不许要记录船经过的港口,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修改过]