其实我一直在强调DDD应该是解决复杂业务场景的方法，对于小项目你完全可以这么干，让customer的内部拥有不同对象的逻辑。
对于复杂场景下出现的问题，我不知道有多少人真正遇到过。

你所理解的复杂是复杂到什么程度？
比如说人 在大众眼中就是实实在在存在的个体
但换做生物研究里 还可以细化到由细胞组成等

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

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

我认为你们两个都有道理，这实际是基本行为和交互行为的区别。

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

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

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

为避免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修改过]