对领域驱动设计的初步认识(一)

10-10-05 flyzb
    首先声明,我只是看了《领域驱动设计精简版》和一些DDD文章(包括banq的),想谈谈自己的认识,如有不足希望大家指正。

    “领域驱动设计”,顾名思义,首先强调的是”领域“。这个词不是指技术上的任何东西,而是指”业务领域“,是说用领域的角度去分析和设计业务。

    可是在现实中我们有多少人又真的懂业务呢,那些低层次的程序员就不用说了,因为他们了解的业务甚至都不是第一手的,都是经过架构师们消化过的。至于那些架构师门了解的业务就是正确的吗,我看不见得。因为就中国的国情而言,尤其对于企业开发而言,处处充满着管理的不规范性,用户说的很多需求就是不规范的。按照这样的用户需求做出的软件只能是个怪胎,满足一时之需,时间一长就不能用了。原因是什么呢,因为用户是会逐步成长和规范的。

    那正确的做法应该是什么呢?答案很简单,向领域专家和专业书籍学习。同时要找出当前用户在业务不足之处在哪里,要在规范和现实之间找到一道桥梁。

    ”领域驱动设计“的另一层含义是”驱动设计“。显然,”设计“只是一种手段和工具,是为”领域“服务的。”设计”的过程和质量必须通过”领域模型“来检验和验证,这也是测试驱动的本质。当然,我们要尽可能不要让设计工具本身的缺陷扭曲了“领域”本身,那就本末倒置了。这就是为什么banq要批判“基于关系数据库的业务设计”以及坚持“域模型不要让技术污染了”。

    在生活中也是如此,如果你骑过车或者开过车,你的心中都有一辆你真正属于你的车,至于这个车是不是有轮子什么的都不重要,关键是能让自己舒适地出行。显然”舒适地出行“才是真正的业务领域,而是”轮子之类的“只是设计。

    做企业开发快10个年头了,遇到很多困惑和困扰,在我的心中也渐渐有一个真正的企业模型。对我来说,”领域驱动设计“其实也是一种”设计“。

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

         

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

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

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

zengogogo
2010-10-06 19:13
有道理

jdkbean
2010-10-13 13:07
迷糊了

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

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

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

猜你喜欢
2Go 1 2 下一页