业务外观、业务规则，它们之间的关系是什么？

Question

最近一直在看Duwamish，对业务层分为业务外观、业务规则不是很明白为什么。Facade模式的用处我是知道的，这个就不用解释了。希望能够针对Duwamish来解释，在Duwamish中我有下面的一些疑点：1、像Customer的密码加密为什么放在业务外观而不是业务规则，这么做是否只是一种设计的方式，而并不是绝对的做法，我同样可以将密码加密的方法放在业务规则中。那么那些操作适合放在在业务外观，那些又应该在业务规则中呢？2、继续上面的，如果业务规则只定义相关业务的操作，其他所需的操作都放在业务外观的话我感觉不到业务外观在这里起到了很好的作用，同是为什么Duwamish中的Select的操作都没有对应的业务规则。3、Insert、Update、Delete、Select 这4个数据库的操作，在Duwamish中只需要Select的数据都没有对应的业务规则而直接在业务外观中实现它的功能，像Product，因为Duwamish没有添加跟修改Product的功能所以他不需要业务规则，按这个道理Delete是否也不需要业务规则？

Answer 1

Duwamish示例虽然很好,但在实际应用中,需要按照自己的习惯划分自己的层次我一般的习惯是    Facade仅输出Html代码,它的表现形式是非常多样的.
                  Rules仅输出DataTable或DataSet,它是相对固定的,因为对表的操作只有那么几种这样,就可以在有了一个完整的Rules后,方便的向页面表现各种样式,而不必去考虑数据的访问但在实际应用中还是有个人习惯在里面,总之,写的多了,觉得自己怎么好用就怎么用,不必非得像示例里那样.

Answer 2

所谓外观，就是给用户提供一组比较一致的调用接口
比如public class UserSystem
{
  GetUser()
  GetUserByID()
  GetUserByAddress()
  UpdateUserByID()
  .....
}
这样用户调用的时候一目了然，业务规则可以不在这里面实现具体的请看设计模式中的 外观模式  Facade Pattern