领域模型-居家旅行，必备之良药？

此话题来自于一个领域模型的高手，而且他不辞辛苦，定期到javaeye上来给大家扫扫领域模型的盲，传传领域模型的道。简直就是领域模型之圣者，社区中那是“唯我独尊”，一统江湖，千秋万载。

之所以如此反感，主要是因为对空谈的反感。当一个领域模型的专家没有错，但是不分条件，自我感觉良好的在那空谈领域模型，然后向大家说：怎么样，我就是领域模型的专家吧？这样就绝对的错了。

我也不喜欢空谈，咱们摆事实，讲道理。

1、什么是 DDD？

很多人都认为是 Domain Driven Development ? 可实际上是 Domain Driven Design。所以人家的重点在 设计，而不是 实现。当然设计与实现保持一致是最好的，不过大家应该分清楚重点在什么地方。

2、看看这个标题：《要领域模型有什么用?》

根据那个高人的水平，起这样一个题目来吸引大家的视线，我觉得其中他应该讨论的是什么情况下我们需要领域模型，什么情况下不需要----这是一个复杂的话题。

可是呢？那个高人最后却只是想引出一个领域模型的实现：qi4j。那还不如直接起个题目叫《java中实现领域模型的方式》---- 因为那个高人从头到尾也没说清楚为什么要领域模型，难道就因为有一个好的实现方式？

那么要领域模型有什么用？DDD这本书告诉我们，引入领域模型，会让我们更加容易的摸清业务逻辑。就这么简单。至于实现方式？那可就多种多样了，根据项目不同，人员素质不同，会是多种多样的。

这里举个简单的例子。

例如一个简单的订购系统。有订货单，以及属于这个订货单的商品明细。ok，这是两个领域模型。有多少种实现方式呢：
1、如果是一个php团队做，90%的可能不会定义两个对象，而是使用sql来处理。
2、如果是一个java团队做，那么 90%的可能会定义这两个对象，但是持久化的逻辑仍然使用dao的方式。大概有 10%的可能会抛弃dao。
3、如果是一个c#团队做，95%的可能会定义这两个对象，但是持久化的逻辑仍然使用dao的方式。大概有 5%的可能会抛弃dao。

当然还有很多别的实现方式----但是这些都不重要！你也不能判断说那个好，那个不好。但是我们唯一能判断的是： 每个团队是否正确的理解了业务！所以在 设计阶段，使用领域模型的方式是正确的，套用类图的5个关系：关联、聚合、组成、泛化、实现，可以描述大部分的业务。如果每个团队都能抽象出这样的概念：订单和明细之间是聚合的关系，那就足够了。

可是那个高人说来说去，说的都是如何实现，实在是没什么意思，即使是另一个新开的帖子，虽然挂上了“领域模型的价值”的羊头，卖的也是“如何实现”的狗肉。

所以我就说，高人哪，如果你再开坛布道，就讲清楚时间和地点以及 主题，免得我们观望的时候云里雾里的，摸不着方向。像有的人摸不着觉得累了，就不摸了，有的人继续仰头摸，结果一不小心掉沟里了---你说多倒霉呀！