领域模型的价值与困境

qi4j莫非是那个用java写函数式程序的组件?

我大概片面理解你的话，在我看来DAO的实现取决于数据的用例。比如，至少可以列举几种实现：

1. SQL DAO，涉及复杂查询的小型数据
2. File DAO, 涉及简单查询的大型数据（比如多媒体)
3. LDAP DAO，涉及集成现有用户认证系统的用户数据
4. MEM DAO，少量频繁访问的数据
5 DUMMY DAO : 0

等等

不是搞组件开发的玩充血就是自找没趣，还是SOA思想来的实在。
这点我觉得你没有理解soa要解决的问题，soa是更具粗粒度（相对于组件），这个只是对于暴露给其他客户端（相对概念）统一借口，并不包含实现，我以为，在soa设计中，考虑的是如何暴露你服务接口，而这些服务的具体实现，并不会全是采用面向服务的设计（其实根本很少，意义不大，只能造成比ejb更尴尬的局面），也就是说，soa主要关注于与外界粗粒度的通信的接口，如何提供恰当的粗粒度。


DAO也是个大忽悠
这个只能说明你们目前面向的应用和业务太少，不能说明其他的问题，或者在你们的项目确实没必要，当然，我不认为一个好项目必须提供dao层。orm的更换应该是很多人遇到的，主要和第三方已有的软件结合，或者是必须和第三方软件结合（可以说是政治问题），这样，往往导致dao层更换，但是服务层是不会受影响的。

当然，最近ror的兴起，使得传统模式的企业开发又一次面临挑战

SOA到底要解决什么问题？不要被什么市场化的SOA宣传理论所迷惑，那都是忽悠至上的言论。

在我看来，服务即契约，面向服务设计即面向契约设计，契约可大可小，大至异构系统间互通的设计，小至一个方法的定义，都应该以契约驱动，将变化封装，何有粗细粒度之分。


你举的是产品的面向第三方接口的例子，先不说目前产品和项目的应用谁多谁少，就拿上述产品例子中访问数据库的代码量来说，需要DAO设计的代码有其他代码20%吗？

按28原则视之，以20%的可能性要求剩下80%也要如此设计，这不是大忽悠是什么？

你认为DDD的价值在哪里？广泛应用大概是个什么景象？

我说点自己的想法，
1.DDD中的Domain Model是一个概念模型 ，ddd中说这要求我们用通用语言来交流它感知它，可赶上了时候咱们基本上用oo来分析它（DDD可没说一定要OO，倒是提了UML和XP的不好），用java来实现它，这里隔着一层加一层呢，然后我们对着java代码平头论足这块贫血这个充血，还有指着一滩POJO说是Domain Model的，似乎有点刻舟求剑的意味。

2.我认为DDD那本书提出的那个应用框架让我原来的想法更加清晰更加系统。这就是DDD暂时给我这样的程序员最大的好处，但同时我认为他也并没有提出其他什么新鲜东西(但估计制止了需求人员抱着UML吓唬客户的歪风邪气)，可能当年书刚出来的时候可能是。有人说DDD让大伙儿让设计更贴近领域需求，难道在这之前我们的需求人员就不是站在客户的角度考虑问题么？OO不是用来更好的模拟显示世界的是非曲直么，DDD顶多算是再提一次醒吧了，然后我们继续OO，跟他有p关系。在我心中，感觉比OO的横空出世差老鼻子远了，感觉，只是感觉啊，这段大家别拍

这里讨论的粗细粒度是指所提供的接口能够解决粗粒度的问题，我不想让你的暴露接口解决问题时，比如发送一份邮件，别人要调用你的暴露的其他接口例如： 判断这个邮件有没有发件人，有没有收件人，然后调用你的send接口发邮件。而应该暴露一个借口sendMail即可。不懂得粒度的粗细 ，如何设计程序？ 举个很简单的j2ee应用的例子：难道你没有使用过任何session fasade模式？


首先，dao层的出现并不只是为了切换不同的数据库，如果这样有hibernate就够你使用了，dao层并未由于hibernate兴起而不复存在，因为他们是解决不同的问题产生的！
第二，这也不代表你完全有权利选择一种orm工具，其他orm工具你有权利不选（特别是“政治”问题） 。
第三，dao的提炼，可以让domain和service更关注自己的业务，每一个对象功能最好专一，完成自己本分的事情，这是面向对象语言设计的基本原则！
第四，你的20-80原则只可能说明你开发设计的软件具有此特征，不需要dao层可能适合你的项目，不一定适合其他所有项目！特别是复杂的，和大型电子商务项目！