clonalman
2012-10-17 21:33
2012-10-17 21:21 "@gameboyLV"的内容
并不存在并发和数据一致性的问题,因为检查余额和扣款是同步事件,在“客户提款”这个大事件里完全可以先锁住用户账号,然后再操作。 ...

如果这样,当然没问题了

检查余额和扣款这两个动作都是在一个场景的有什么矛盾?把这个两个动作封装为两个事件有点多余!

客户提款粒度比较大,可能还需要其他场景支持,如检查客户的合法性等。。。

[该贴被clonalman于2012-10-17 21:37修改过]

[该贴被clonalman于2012-10-17 21:41修改过]

gameboyLV
2012-10-17 21:47
如果我是双币信用卡,检查余额需要分别检查人民币和美元呢?检查人民币需要银联来处理,检查美元需要VISA来处理,如果做成事件就方便多了,以后接入欧元的业务也不用更改代码。

clonalman
2012-10-17 21:48
事件、契约设计与BDD,我们必须分清几个交互行为:

用户与系统的交互

应用层与领域层的交互

应用层与基础设施层的交互

领域层与基础设施层的交互

领域层与领域层的交互

gameboyLV
2012-10-17 21:54
2012-10-17 21:48 "@clonalman"的内容
域层与基础设施层的 ...

我们讨论的应该是“领域层与领域层的交互”吧

用户与系统的交互 这个AJAX或MVC都可以

应用层与领域层的交互 这个用领域服务

应用层与基础设施层的交互 这个用AOP

领域层与基础设施层的交互 这个用ORM

jdon007
2012-10-17 23:48
1)事件

描述一个事件的可能形式如下:

事件 {

属性:

参与该事件的若干个对象

方法:

1)检查事件发生的条件是否满足

2)事件发生

}

在事件中,实体是直接交互的。

2)角色

描述一个角色的可能形式如下:

角色 {

事件1,

事件(2,3),

事件4,

事件5

}

事件之间组合(composition)为一个复合事件,比如事件(2,3)。

事件聚合(aggregation)为角色(从角色身上可以知道其可以做哪些事,角色的意义在于此)。

3)场景

场景 {

属性:

参与场景的若干个角色

方法:

触发角色身上事件的发生

}

在场景中,实体是通过角色间接交互的。

4)系统

一个系统的描述,总得来说可以从两个角度进行:可见性和可控性。

“模型-行为特征(角色/事件)-场景”,以符合直觉的方式描述了系统的可控性。

事件改变模型,角色聚合事件,场景激活角色产生事件,实现模型之间的交互。

系统是动态变化的,可以根据时间段或时间点对系统的状态进行切分,切分之后,即系统可由一系列相互独立又相互联系的场景(画面)进行描述。

此外,"Given-When-Then"和"Event-Context-State",似乎与"Input-Process-Output"的描述方式并无差异?只是以黑盒的方式描述系统或场景,对于要描述系统的可见性和可控性(白盒)似乎仍不够。

猜你喜欢