对领域驱动设计的初步认识（一）

    首先声明，我只是看了《领域驱动设计精简版》和一些DDD文章（包括banq的），想谈谈自己的认识，如有不足希望大家指正。
    “领域驱动设计”，顾名思义，首先强调的是”领域“。这个词不是指技术上的任何东西，而是指”业务领域“，是说用领域的角度去分析和设计业务。
    可是在现实中我们有多少人又真的懂业务呢，那些低层次的程序员就不用说了，因为他们了解的业务甚至都不是第一手的，都是经过架构师们消化过的。至于那些架构师门了解的业务就是正确的吗，我看不见得。因为就中国的国情而言，尤其对于企业开发而言，处处充满着管理的不规范性，用户说的很多需求就是不规范的。按照这样的用户需求做出的软件只能是个怪胎，满足一时之需，时间一长就不能用了。原因是什么呢，因为用户是会逐步成长和规范的。
    那正确的做法应该是什么呢？答案很简单，向领域专家和专业书籍学习。同时要找出当前用户在业务不足之处在哪里，要在规范和现实之间找到一道桥梁。
    ”领域驱动设计“的另一层含义是”驱动设计“。显然，”设计“只是一种手段和工具，是为”领域“服务的。”设计”的过程和质量必须通过”领域模型“来检验和验证，这也是测试驱动的本质。当然，我们要尽可能不要让设计工具本身的缺陷扭曲了“领域”本身，那就本末倒置了。这就是为什么banq要批判“基于关系数据库的业务设计”以及坚持“域模型不要让技术污染了”。
    在生活中也是如此，如果你骑过车或者开过车，你的心中都有一辆你真正属于你的车，至于这个车是不是有轮子什么的都不重要，关键是能让自己舒适地出行。显然”舒适地出行“才是真正的业务领域，而是”轮子之类的“只是设计。
    做企业开发快10个年头了，遇到很多困惑和困扰，在我的心中也渐渐有一个真正的企业模型。对我来说，”领域驱动设计“其实也是一种”设计“。

[该贴被flyzb于2010-10-05 16:35修改过]

写得很好，不愧是有10年经验的老手，宏观微观都把握到位，对DDD认识也非常可观，也能对其非常精确的到位，这就是经验修行到家的自然体现，所以，看软件行业概念层出不穷，以为越年轻越容易掌握，实际相反，年轻了反而不容易掌握新概念，因为这些概念都是承上启下，没有经验，很难入门，也是很多年轻程序员对DDD难以理解，甚至忽视的根本原因。

再加上中国的计算机教育体系只培训程序员技术概念，要么是极其基础的数学编译原理，妄图让每个计算机专业毕业的人都能发明一套伟大的语言(国人人多，淹死老外)，从来没有告知他们有一种实用技巧叫面向对象，等他们在实践中走了很多弯路之后，他们也可能就离开计算机行业，后来的人再重新走老路，可惜啊。有点跑题，打住了。

领域驱动设计和现在敏捷工程以及测试驱动都是浑然一体的，三者紧密结合，形成一套新的软件开发方式，而且已经开始普及和成熟，当然更有甚者专门开发出MDD工具或DSL来支持领域开发，这些都属于探索，还没有非常成功案例，见：InfoQ:模型驱动开发在哪里成功了？

有道理

迷糊了

楼主对领域驱动设计的领悟很到位，如果连软件要解决的问题是什么？这些问题是什么领域的问题都没搞清楚，我想这个软件虽然可以暂时实行了功能，但是它没有灵魂，而软件真正的生命力就体现在了领域模型上，正是领域模型让软件的生命力更强.

话又说回来了，并不是任何地方都适合领域驱动设计，领域驱动设计适合一些相对稳定的行业或者领域，比如泛金融，包括银行，保险等，物流，医疗健康等领域，这些领域概念相对稳定，所以领域相对稳定，也相对更容易通过领域分析分析出领域模型出来，但是对于目前发展迅速的互联网行业，我也一直在探索是否真的适合领域驱动设计呢？比如互联网的流行的社会化媒体，包括SNS，Twitter,Digg,Groupon，Flickr等，这些领域发展较快，并且变化也很快，领域模型如何做到快速适应变化，既然领域模型要经常变化，那么说明这个领域模型就有问题，一个真正的领域模型，我觉得应该是能体现领域实质的，是领域本质的抽象，并不会经常发生变化才对，因此我觉得对于这些快速发展的行业，可以利用面向对象的分析和设计，比如四色原型的分析方法，但是领域设计并不一定适合。

ps:我觉得如果不了领域概念做出来的软件，就跟充气娃娃一样没有生命力，即使表面做的再像，可是毕竟没有灵魂啊

看到一片文章中有这么句话，“OOAD的基本主张，认为领域概念是相当稳定的，可视其为企业的基因(Gene)。如果企业信息系统也是建立在此基因上，则企业与系统的基因是一致的(Consistent)，让企业与系统成为一体的(Unified)两面……”，我不知道OOAD的这些基本主张是否属实，也没地方能得到验证，如果是对的话，楼上说的面对快速变化的行业领域模型不适用的说法，就是错误的，只能说明你尚未把业务做到位，领域模型尚不成熟。

2010年10月14日 10:06 "daihoujian"的内容

看到一片文章中有这么句话，“OOAD的基本主张，认为领域概念是相当稳定的，可视其为企业的基因(Gene)。如果企业信息系统也是建立在此基因上，则企业与系统的基因是一致的(Consistent)，让企业与系统成为一体的(Unified)两面… ...

首先任何事物都有它的适用性，软件行业不存在银弹，领域驱动设计也是，我们不能为了领域驱动设计而去领域驱动设计，还是要搞清楚它的适用范围，对于一些新兴行业，本身这个领域刚刚兴起，领域本来就不稳定，那怎么搞领域驱动设计，另外领域驱动设计中有个很关键的角色：领域专家，当一个领域刚刚兴起的时候，大家都处于探索阶段，很难抽取出一个合适的领域模型的。

另外我再说一下自己的一些想法，领域驱动设计中有实体的概念，这个概念我觉得大家不要把他等同于我们hibernate等底层持久框架的实体，领域驱动设计的实体是要讲究状态封装的，而hibernate/ibatis等框架必须要暴漏状态，比如必须有getter/setter等方法，因此这个地方需要注意，领域模型中的实体是我们面向业务的实体，没有技术上面的概念，我现在的做法就是领域模型中实体和数据库对应的那个实体对象是区别对待的。

另外一个问题，在一个分布式的系统中，每天系统之间的交互次数都非常大，比如目前我所在部门的系统之间通过远程接口调用次数每天都在数亿次，整个公司通过远程接口调用的次数每天在100+亿次，而有时候我们的领域模型实体对象往往因为充血行为，而具有太多的关联数据，而此时在系统之间传递的时候，必然会引来很大的网络开销，同时对象序列化也是一种开销，这个时候我们在系统之间传递对象的时候，就要考虑是否适合传递领域模型实体对象。

最后，领域驱动设计中还有一个关键概念就是界限上下文，这个概念很重要，比如有时候随着系统的发展，你会发现原来你模型中的某个属性是int类型的，但是发现int类型不够用了，要移除，要改为long类型的，这个时候如果你的领域模型是没有经过界限的，没有经过划分的，那么这一次改动就会牵扯到非常多的系统，包括系统客户端升级，服务器端升级等等，而且也许会牵扯到其它的数10个，甚至更多的系统的时候，这个成本是非常大的。举着例子也是想说，领域驱动设计中模型之间的隔离很重要，虽然领域模型是系统共享的，我们一定要划分清楚共享的范围.
[该贴被xmuzyu于2010-10-14 12:27修改过]

听起来蛮有用的，和RUP有啥联系没有？

很受用，学习中。领用模型原来我一直在用，只是没有理论化。关注中。