对领域驱动设计的初步认识（二）
原文http://www.jdon.com/jivejdon/thread/39472
flyzb
发表文章:18
注册时间:2010年10月01日
悄悄话
个人博客
在线?当前离线
我要关注该作者发言1人关注
对领域驱动设计的初步认识（二）2010年10月14日21:56收藏关注本主题到本帖网址加入本帖到收藏夹请用鼠标选择需要回复的文字再点按本回复键回复该主题
标签DDD领域驱动设计软件观点
1
顶一下
对于上一个帖子，大家有一些讨论。有人说“领域驱动设计”非常好，也有人说“领域驱动设计”有问题。其实大家都有道理，我针对大家的讨论进一步谈一下自己的认识。
先谈谈现实业务中的问题域模型，这个模型不是“领域驱动设计”一书中的“领域”，那个“领域”更侧重强调是“领域模型”。可惜目前似乎还没有一种办法能够去立体化并动态地完整描述这个“问题域模型”。为什么我要强调这个东西，就是让大家想一想我们为什么要需要“领域驱动设计”。其实我们有一个永恒的技术使命，就是要解决“问题域模型”的变化问题，因为“领域模型”会存在与”问题域模型“不匹配的问题，这个可能是时间变化或者用户场景变化的原因造成的。对”领域模型“的检验标准就是看是否能适应”问题域模型“的变化，其中”开闭原则“是在这里适用的。
所以对"领域驱动设计"的第一层”驱动“的含义，我觉得是"问题域模型"驱动"领域建模"以及"测试建模"。从这一点来说，"领域驱动设计"是适合一切场景的，而有人说”领域驱动设计“有问题，准确地来讲是目前的"领域建模技术"还不完善，当然也可以说是"领域建模技术"的运用有问题。这就像最近有人说"面向对象编程走错了路"，其实并不是真的说OO错了，而是说"传统OO"有很大的缺陷，首先第一条就是"没有面向消息的传递机制"。
对于有人说“领域建模”只适应“稳定领域”，我并不赞同。我认为领域建模的真谛是认清业务发展变化的脉络，其最高境界就是“庖丁解牛”。因为真实世界中并不存在“稳定领域”，业务的变化是一种永恒。如果业务永远不变，那就我们就真的幸福了，只要满足用户需求，怎么设计都可以了。
关于"领域驱动设计"的第二层含义在上一个帖子里已经分析过了。
总结一下，"领域驱动设计"=“问题域模型驱动领域建模”+“领域建模驱动软件实现”。
呵呵，总算买了一本Eric的注释版，后面将真正进入“领域建模技术”的学习，望与大家共勉。另外，我也不赞同在远程交互中传递复杂的领域对象。
[该贴被flyzb于2010-10-1423:06修改过]
xmuzyu
发表文章:432
注册时间:2007年03月26日
悄悄话
个人博客
在线?我在线上
我要关注该作者发言18人关注
回复:对领域驱动设计的初步认识（二）2010年10月14日23:15收藏关注本主题到本帖网址加入本帖到收藏夹请用鼠标选择需要回复的文字再点按本回复键回复该主题
顶一下
2010年10月14日21:56"flyzb"的言论
对于有人说“领域建模”只适应“稳定领域”，我并不赞同。我认为领域建模的真谛是认清业务发展变化的脉络，其最高境界就是“庖丁解牛”。因为真实世界中并不存在“稳定领域”，业务的变化是一种永恒。如果业务永远不变，那就我们就真的幸福了，只要满足用户需...
你说的变化，我认同。其次你稳定的理解有点问题，我没说什么稳定领域，我是说相对稳定，是这个行业已经出现好多年了，本身行业积累也比较丰富了，大家对行业的认识也都有一个大致统一的认识，而对于一些新起行业，前期都处于探索阶段，这个领域根本不稳定，或者大家都没有对这个东西形成共识，如果前期采用领域驱动设计，你抽象出的那些东西不一定能经得起时间的考验，当然这不能怪你，因为大家对这新的东西，创意型的东西都还没有共识，这就需要通过积累去完善，但是对于此种类型的项目，尤其是互联网项目，项目周期都很短，如果你项目上线晚了，也许就失去了上线的意义了，而此时如果为了领域驱动设计而去领域驱动设计，只能拖了项目的腿，还不如初期先采用一种折中的方式，先按照大家都能普遍接受的一种方式做，以后再重构，随着后期的发展，大家对领域概念都认识清楚了，或者说领域概念慢慢凸显出来了以后，这个时候再领域驱动设计，总之，领域驱动设计的前提是你得认清楚领域的实质，需要时间的积累，并不是任何团队都可以在项目时间容许的范围内搞的定的.
最后还是那句话，领域驱动设计是好，但是不要企图任何项目都适用。
[该贴被xmuzyu于2010-10-1423:17修改过]
flyzb
发表文章:18
注册时间:2010年10月01日
悄悄话
个人博客
在线?当前离线
我要关注该作者发言1人关注
1楼对领域驱动设计的初步认识（二）2010年10月14日23:56收藏关注本主题到本帖网址加入本帖到收藏夹请用鼠标选择需要回复的文字再点按本回复键回复该主题
顶一下
Toxmuzyu
我明白你的意思了。对于你说的情况，我说的“第一层含义”仍然是成立的。不过对于原型或者快速开发的问题，我认为“领域驱动设计”仍然是适用的。不是说领域相对稳定了或者成熟了，才可以进行“领域驱动设计”，而我认为“领域驱动设计”恰恰在业务不成熟时的分析过程中价值更大。因为越是不成熟的业务越是变化快，而这时候需要从多种领域维度分析业务可能变化。问题域建模的过程就是业务领域分析的过程，对于企业而言就是业务架构的分析和建立过程，这里不包含任何OO的设计成分，主要从组织、流程和业务能力三个维度来分析业务。对于不同的企业，还要从不同企业的组织以及各方面的特点去分析为什么这个企业的业务是这个样子，对于新兴的SNS网站也同样如此。
对于Eric提出的东西，我认为更多的是一种领域建模技术。你说的不足，我感觉更多的是这种技术的不足，但不能去指责思想本身。
另外，对于用户业务的不成熟。我们应该去分析真正的业务是什么样子，而用户的业务为什么是这个样子。好的领域建模应该具有柔性，能够伴随着用户一起成长。如果国内企业管理规范了，我估计国内很多小公司都会没有饭碗的，因为他们的生存机会其实就是中国用户的管理不规范性。当然，对于我们做领域建模的，是不是也应该有一些骨气。
对于项目的快与不快，首先看做项目的目的是什么：挣银子，还是真的做好项目。扭曲的领域建模，比如基于关系数据库表设计的建模，也许在初期的开发效率上满足用户的需求，但是上线后的适应性更改就可能慢了。往往用户认为大体的业务基本差不多了，只要小小的一点更改就可以了，可实际设计上需要大量的更改，这样的例子应该很多。“领域建模”做得好，软件的适用性强，意味着这个模型也能快速地推广到其他用户，这样软件开发的利润才能最大化。
[该贴被flyzb于2010-10-1500:14修改过]
xmuzyu
发表文章:432
注册时间:2007年03月26日
悄悄话
个人博客
在线?我在线上
我要关注该作者发言18人关注
回复:1楼对领域驱动设计的初步认识（二）2010年10月15日00:41收藏关注本主题到本帖网址加入本帖到收藏夹请用鼠标选择需要回复的文字再点按本回复键回复该主题
顶一下
2010年10月14日23:56"flyzb"的言论
对于项目的快与不快，首先看做项目的目的是什么：挣银子，还是真的做好项目。扭曲的领域建模，比如基于关系数据库表设计的建模，也许在初期的开发效率上满足用户的需求，但是上线后的适应性更改就可能慢了。往往用户认为大体的业务基本差不多了，只要小小的一...
恩，认同你的一些观点。不采用领域驱动设计并不一定是面向关系库设计。采用领域驱动设计是一个起初慢，但是越到后期越快的方式，这其实就是领域驱动很关键的一点，因为随着项目的发展，我们将对领域的理解，慢慢重构到了领域模型中，那么这个领域模型必将越来越能经得起考验。但是做领域驱动设计前期要做的工作很多，如果一个项目没有时间限制，没有上面给你的压力，即使这个项目是产品经理一时脑子发热想出来来的奇思妙想，你完全可以按照领域驱动设计去做，因为有时间，领域的概念你可以花很多时间去抽取，去积累，当然这种情况很少。所以我说并不是任何项目或者任何项目的任何生命周期里都适合领域驱动设计，也许有些项目上线后发现市场反应不行，后期都不做了，你前期花了那么多精力和时间搞出来的东西是不值得的，所以还是要有把握好领域驱动设计切入到项目周期的时机。
另外不要什么都领域驱动设计，要综合考虑其他方面的因素，比如项目周期，项目本身的逻辑是否复杂等，不要一味的啥都要来一把领域驱动设计，这样反而让领导觉得，你说领域驱动设计多好多好，怎么做了这么久第一期还没出来。所以为了让领域驱动设计走的更远，我们最好把握个度，这个度很重要，虽然我本人也一直坚持领域驱动设计，也在公司极力倡导领域驱动设计，但是要想让领域驱动设计真正运用到互联网项目里，我还需更加努力。
flyzb
发表文章:18
注册时间:2010年10月01日
悄悄话
个人博客
在线?当前离线
我要关注该作者发言1人关注
1楼对领域驱动设计的初步认识（二）2010年10月15日08:14收藏关注本主题到本帖网址加入本帖到收藏夹请用鼠标选择需要回复的文字再点按本回复键回复该主题
顶一下
嗯。。表示理解。作为我们自己，首先是一种坚持。目前很多公司都很浮躁，这也是现实。