banq
2012-10-18 12:07
2012-10-17 20:25 "@clonalman"的内容
实体间交互应该是同步直接发生,事件应该发生在不同场景下异步行为 ...

我是这样思考的,聚合体内部应该是同步,而聚合体之间应该用异步事件。

领域和领域之间使用事件,实际上是聚合体之间使用事件,基本上是一个聚合体(聚合根和其对象群)代表一个领域。

从结构上看,聚合边界是结构上的“场景”,而我们通常意义上的“场景”应该是行为发生的边界。

既然场景是一个行为概念,它大概不应该如同结构性概念一样存在属性等特征,按照契约设计原则,行为概念只有前置条件和后置条件,你可以将这两者等同于结构概念的属性。

题外话:本主题讨论的意义?

[该贴被banq于2012-10-18 13:10修改过]

banq
2012-10-19 10:43
2012-10-17 23:48 "@jdon007"的内容
此外,"Given-When-Then"和"Event-Context-State",似乎与"Input-Process-Output"的描述方式并无差异?只是以黑盒的方式描述系统或场景,对于要描述系统的可见性和可控性(白盒)似乎仍不够。 ...

我思考结果是这样:白盒是否应该就是领域模型呢?

场景-事件-状态 <==> 实体-聚合-领域

等式左边侧重行为,右边侧重结构,结构和行为衔接点通过实体的状态结合在一起。

实则这个等式也是函数语言和类型语言结合。也是逻辑上证明与类型的一种结合。

落实到日常开发交流中,需求人员只要向开发人员交待了这几个点,开发人员就能够迅速落地,希望这是一个接地气的大道至简的公式。

公式反过来也可以:

领域-聚合-实体 <==>状态-事件-场景

这比较符合类型为第一的思维,前者是函数为第一first class的思维。

我们通过本帖的讨论,将任何业务逻辑分解为上面这个公式,将业务逻辑真正接地,功效可见这个帖子:有个疑问困扰了很多年了~

与@clonalman 讨论业务建模:BoundedContext(有界上下文),DDD中的有界上下文根据我的观点可以初步看成等同于本帖的场景,这样用这套公式也可以涵括老外的DDD和DCI等等理论。

总结图如下:

[该贴被banq于2012-10-20 07:28修改过]

clonalman
2012-10-20 08:16
2012-10-19 10:43]banq"的内容
" border='0' loading='lazy' >

上图还应该体现服务的概念,Command、Event Bus、这些都带有技术特征,

模型应该是这样:

Command

V

V-----| V---------------------------|

服务->场景->聚合根(实体)->实体->事件(实体)

V

DB、Event Bus...

架构都通过服务过渡一下,两个闭环结构, 服务三个层次:基础设施服务、领域服务、应用服务

应用层与领域层调用都通过设施服务(持久化、消息机制等....)

应用层对领域层调用通过领域服务(业务请求)

领域层之间调用通过领域服务(业务处理)

应用层之间调用通过应用服务(不同调用粒度)

有点transaction script的味道

-

[该贴被clonalman于2012-10-20 08:59修改过]

banq
2012-10-20 09:35
2012-10-20 08:16 "@clonalman"的内容
服务->场景->聚合根(实体)->实体->事件(实体) ...

是否引入服务要值得商榷,服务其实也是一种DBC的contact实现,比如通常的服务合同,就是规定服务提供商和服务使用者客户之间的权利和义务。而我们这里已经引入了领域事件,有些重复。

所以,如果没有服务,调用顺序将是这样:

Uses发出Command -->MVC的Controller -->聚合根实体 -->场景 -->事件--->状态。

这样保证在OO结构下实现可管理的FP函数式编程。而如果使用服务,则可能相当于打开函数调用的潘多拉盒子,行为调用满天飞,回到过去面向过程的编程,也杜绝了事务脚本(Spring/EJB)的味道。

具体可见我这篇英文文章,中文就不想写了,有些罗嗦:http://www.dzone.com/links/cescontext_event_and_state.html

[该贴被banq于2012-10-20 09:39修改过]

gameboyLV
2012-10-21 13:59


用户点击UI上的某个元素触发command,command到达合适的场景后获取command的处理流程,流程的每一个节点均是事件。

现在command工作流开始运转,将节点事件依次发送给EventBus,EventBus将节点事件分配给合适的领域进行处理,处理完毕后EventBus根据各领域反馈的处理情况计算出command的处理结果。

工作流流转结束。

[该贴被gameboyLV于2012-10-21 14:00修改过]

[该贴被gameboyLV于2012-10-21 14:00修改过]

[该贴被gameboyLV于2012-10-21 14:01修改过]

猜你喜欢