flyzb
2013-05-11 09:41
2013-05-10 23:06 "@aixs

"的内容

检查钱包里的金额是否足够支付是customer的一部分

至于说刷卡支付,这只是customer的一种委托支付的形式 ...

其实我一直在强调DDD应该是解决复杂业务场景的方法,对于小项目你完全可以这么干,让customer的内部拥有不同对象的逻辑。

对于复杂场景下出现的问题,我不知道有多少人真正遇到过。

aixs
2013-05-11 10:35
2013-05-11 09:41 "@flyzb

"的内容

其实我一直在强调DDD应该是解决复杂业务场景的方法,对于小项目你完全可以这么干,让customer的内部拥有不同对象的逻辑。

对于复杂场景下出现的问题,我不知道有多少人真正遇到过 ...

你所理解的复杂是复杂到什么程度?

比如说人 在大众眼中就是实实在在存在的个体

但换做生物研究里 还可以细化到由细胞组成等

在不同的系统中对象的分解程度是不一样的

flyzb
2013-05-11 10:50
2013-05-11 10:35 "@aixs

"的内容

你所理解的复杂是复杂到什么程度?

比如说人 在大众眼中就是实实在在存在的个体

但换做生物研究里 还可以细化到由细胞组成等

在不同的系统中对象的分解程度是不一样的 ...

我说的复杂不是指“纵向切分”的,而更多的指横向关联性的复杂。在业务分析中,customer是一个很特殊的对象。在很多业务场景中,customer都是主动参与进行的。如果开始你只是设计其中一个业务场景,让customer内部耦合这个场景的业务似乎没有问题。但随着业务不断增长变化,customer负责的业务越来越多,难道你让customer继续和不同的业务场景就这样简单的耦合下去吗?在我的设计经验中,这样容易出现混乱,也就是说这样的设计会造成“逻辑设计上的伸缩性”不好,所以我才会质疑这种设计的合理性。

banq
2013-05-11 11:33
我认为你们两个都有道理,这实际是基本行为和交互行为的区别。

设计领域模型行为时,要辨识哪些是基本行为,哪些是交互行为。

迪米特法则只是规定了对象的基本行为,除此以外可以看成都是交互行为。

而交互行为都是基于一定业务场景发生的多个对象之间交互行为,因此交互行为也可以认为是一种场景行为。

为避免Customer这样领域模型行为过于复杂,肯定不能将交互行为也放入Customer中,实现场景职责行为有两种方式:

1. DCI注入。在运行时将需要的场景行为注入到Customer中。这属于一种动态组合,也就是编程时不必放入太多行为,而是在代码运行时自动混合。

2. 消息实现。保持原有对象结构不动,交互通过发送消息实现,消息是信封,信封的内容是命令或事件,命令和事件都是指挥行为的指令,是行动目标,都需要响应并且辅之以实现。

http://www.jdon.com/45385

也就是说:我们将每一次交互行为分解为目标和响应两个部分,这也是Tell don't Ask原则,目标和响应的区别也是Tell和Ask区别,Tell是只是告诉目标,Ask是询问细节。

相关贴:

实体验证合法性

[该贴被banq于2013-05-24 12:19修改过]

猜你喜欢
4Go 上一页 1 2 3 4