lovko，
我一看你的回复的内容的特点写法，我应该就知道你是谁了，eric吧？呵呵。

首先，我先批评你一下，你的表达不够清晰，恐怕banq无法很好的把握你的核心意思；
其次，貌似你引入的概念太多，交流最好基于大家都认同且熟悉的词语去表达；

不过也看看banq如何回复你吧，呵呵。其实我并不认为banq和你说的是两个意思。建议你最好能再用两三句简洁的话明确的表达出你认为和banq的不同想法，这样可以更有效的交流；也能让旁观者明确知道你的核心观点。
[该贴被tangxuehua于2013-04-24 21:46修改过]

2013-04-24 21:42 "@tangxuehua
"的内容
我一看你的回复的内容的特点写法，我应该就知道你是谁了，eric吧？呵呵 ...

呵呵，有眼力！上次群里讨论到，所以来主要是来发表下不一样的看法。
2013-04-24 21:42 "@banq"的内容

总体是对这种设计从边界职责划分上不太认同。

1、不过主要针对点就是不管角色是否从外部注入到领域内部的，然后通过消息委派出去。我的观点是【领域聚合不应该对任何对业务场景进行了解，而是业务场景去了解并使用聚合】，要做就要做到彻底，banq种设计我的理解上有点不伦不类了。
2、主因是边界划分一定程序上觉得不认同。聚合你对内进行一切动作可以具有主动性，掌握聚合内部状态的上下文环境，你可以做你想做的控制和行为。但一旦你给外包公开了公共接口，那外部的业务场景把你放在一个什么位置或角色上就你就不用操心了。

  其实对于DDD中的“领域”、“聚合”、”一致性“几个概念，我觉得大家都是认同的，没有什么大的问题。

  但对于“聚合的方式”，尤其是“聚合根”，我表示异议。因为对于“聚合根”，打个比喻，有点像“家长”，对外严防（唯一的访问接口），对内死守（要保持内部的一致性）。对于经常变动的企业复杂业务而言，这个”聚合根“的定位就有可能发生变化，是我很难接受的。一开始是小系统，家长还能管住孩子，但业务逐步复杂（孩子要单飞了），这个”聚合根“对于”不断迭代的企业软件开发“就会变成一种灾难。

  所以，我希望能有一中”更自然、更灵活“，能够适应业务变化的”聚合方式“。

2013-04-25 12:30 "@flyzb
"的内容
所以，我希望能有一中”更自然、更灵活“，能够适应业务变化的”聚合方式“。 ...

前辈，这就是你一直推崇的用类似人体的基于消息的刺激响应的模式才是最终解决数据一致性的方法了对吧？你这个观点从我第一天认识你开始我记得你就是这个思想的，现在你依然是这个思想，你的坚定信让我很佩服。

但我觉得最好你能举个让大家可以讨论的例子，说明传统的基于聚合根的方式来确保数据一致性方面，虽然可以确保数据一致性，但随着业务的不断复杂，聚合根反而会成为累赘。然后说明用你的思路可以解决这个问题，那我想大家就都会积极认同你了，然后你可能就成为了即Eric Evans之后的第二个在DDD方面有很大影响力的人了，哈哈。

期待中。。。

在领域模型的行为设计中我们提到

2013-04-22 15:37 "@banq
"的内容
我们把A对象自身固有行为看成是A的一种能力，而把需要依赖其他对象的方法称为交互行为。哪些属于A的自身方法？哪些属于交互方法？设计思路和方法是如何考虑的？ ...

那么什么是对象的固有行为？我们认为是那些保证该对象逻辑一致性的行为，称为对象的基本职责，保证自己的存在。

迪米特法则(Law of Demeter)则详细地定义了对象的方法行为，其定义是：

一个对象的方法只应该调用下面对象的方法：
1. 可以调用自己的方法
2. 参数对象的方法
3. 创建自己或初始化时涉及到其他对象的方法
4. 它的直接对象的方法(聚合体内部等)


迪米特法则实际从一个公理原则角度对对象的行为设计进行了界定，举例如下：
顾客有一个钱包，PayBoy收款员要求顾客支付，首先，顾客对象如下：


public class Customer {
 private String firstName;
 private String lastName;
 private Wallet myWallet;
 public String getFirstName(){
 return firstName;
 }
 public String getLastName(){
 return lastName;
 }
 public Wallet getWallet(){
 return myWallet;
 }
}

钱包：


public class Wallet {
 private float value;
 public float getTotalMoney() {
 return value;
 }
 public void setTotalMoney(float newValue) {
 value = newValue;
 }
 public void addMoney(float deposit) {
 value += deposit;
 }
 public void subtractMoney(float debit) {
 value -= debit;
 }
}

收款员进行收款时代码如下：


//这段代码是位于Payboy类中：
 payment = 2.00; // “I want my two dollars!”
 Wallet theWallet = myCustomer.getWallet();
 if (theWallet.getTotalMoney() > payment) {
    theWallet.subtractMoney(payment);
 } else {
   // come back later and get my money
 }

这段代码的意思是，检查顾客的钱包中余额，是否足够，然后支付。

注意，检查顾客钱包中余额这一功能是在PayBoy中实现的，PayBoy有权检查顾客的钱足够吗？应该是顾客知道自己钱包余额是否足够。

如果类似Payboy这样调用者进行下面代码：
myCustomer.setWallet(null);

这不是将顾客这个对象的钱包清空了吗？

这实际就是破坏了顾客这个对象内部的逻辑一致性，顾客对自己的钱包拥有支配权，不能随便将钱包的操作暴露给外界。

也就是说问题出在Customer，它只有setter/getter方法，是一种纯粹的数据结构，是一种失血模型。

我们需要重构Customer，将保证顾客逻辑一致性的行为显式的表达出来，顾客应该拥有这样的基本职责：对自己钱包余额情况有足够了解。

代码实现如下：


public class Customer {
 private String firstName;
 private String lastName;
 private Wallet myWallet;
 public String getFirstName(){
 return firstName;


 public String getLastName(){
   return lastName;
 }
 public float getPayment(float bill) {
   if (myWallet != null) {
      if (myWallet.getTotalMoney() > bill) {
         theWallet.subtractMoney(payment);
       return payment;
      }
    }
 }
}

我们看到，将钱包检查验证是否足够放在Customer这个对象中，这实际也回答了“关于领域驱动设计中的“合法”性校验？”：
http://www.jdon.com/45363

这样Payboy的调用代码如下：


payment = 2.00; // “I want my two dollars!”
 paidAmount = myCustomer.getPayment(payment);
 if (paidAmount == payment) {
 // say thank you and give customer a receipt
 } else { 
 // come back later and get my money
 }


迪米特法则可能带来Customer行为增加，导致复杂性，其实熟悉DDD应该知道，我们可以使用规格模式Specification将那些确保
实体逻辑一致性的合法性检查划分出去，这样，Customer和那些规格对象就组成一个聚合群，成为一个聚合体。

建议banq出一本领域驱动设计的书，像DCI 这一类的知识都包含进来，现在这一块的书很少，而且都写得很抽象呀。

其实这就是对对象的认知问题吧。比如说一个人，能话会走，各个零件都全才是一个完整的人。你说零件都有了。但不会说不会走的木偶能称做人吗。
一个对象具有完整的属性与行为才是一个真正意义上的对象。
行为本来就是通过它自身的属性来完成的。

领域模型的行为设计+用户的行为设计=事件驱动EDA

通过消息或事件将这两者的行为联系上，不但可以得到稳定的可伸缩的软件架构，而且能够取得最佳的用户体验，一举两得：
基于任务的UI

上页