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

你说的变化，我认同。其次你稳定的理解有点问题，我没说什么稳定领域，我是说相对稳定，是这个行业已经出现好多年了，本身行业积累也比较丰富了，大家对行业的认识也都有一个大致统一的认识，而对于一些新起行业，前期都处于探索阶段，这个领域根本不稳定，或者大家都没有对这个东西形成共识，如果前期采用领域驱动设计，你抽象出的那些东西不一定能经得起时间的考验，当然这不能怪你，因为大家对这新的东西，创意型的东西都还没有共识，这就需要通过积累去完善，但是对于此种类型的项目，尤其是互联网项目，项目周期都很短，如果你项目上线晚了，也许就失去了上线的意义了，而此时如果为了领域驱动设计而去领域驱动设计，只能拖了项目的腿，还不如初期先采用一种折中的方式，先按照大家都能普遍接受的一种方式做，以后再重构，随着后期的发展，大家对领域概念都认识清楚了，或者说领域概念慢慢凸显出来了以后，这个时候再领域驱动设计，总之，领域驱动设计的前提是你得认清楚领域的实质，需要时间的积累，并不是任何团队都可以在项目时间容许的范围内搞的定的.

最后还是那句话，领域驱动设计是好，但是不要企图任何项目都适用。

[该贴被xmuzyu于2010-10-14 23:17修改过]

To xmuzyu
    我明白你的意思了。对于你说的情况，我说的“第一层含义”仍然是成立的。不过对于原型或者快速开发的问题，我认为“领域驱动设计”仍然是适用的。不是说领域相对稳定了或者成熟了，才可以进行“领域驱动设计”，而我认为“领域驱动设计”恰恰在业务不成熟时的分析过程中价值更大。因为越是不成熟的业务越是变化快，而这时候需要从多种领域维度分析业务可能变化。问题域建模的过程就是业务领域分析的过程，对于企业而言就是业务架构的分析和建立过程，这里不包含任何OO的设计成分，主要从组织、流程和业务能力三个维度来分析业务。对于不同的企业，还要从不同企业的组织以及各方面的特点去分析为什么这个企业的业务是这个样子，对于新兴的SNS网站也同样如此。
    对于Eric提出的东西，我认为更多的是一种领域建模技术。你说的不足，我感觉更多的是这种技术的不足，但不能去指责思想本身。
    另外，对于用户业务的不成熟。我们应该去分析真正的业务是什么样子，而用户的业务为什么是这个样子。好的领域建模应该具有柔性，能够伴随着用户一起成长。如果国内企业管理规范了，我估计国内很多小公司都会没有饭碗的，因为他们的生存机会其实就是中国用户的管理不规范性。当然，对于我们做领域建模的，是不是也应该有一些骨气。
    对于项目的快与不快，首先看做项目的目的是什么：挣银子，还是真的做好项目。扭曲的领域建模，比如基于关系数据库表设计的建模，也许在初期的开发效率上满足用户的需求，但是上线后的适应性更改就可能慢了。往往用户认为大体的业务基本差不多了，只要小小的一点更改就可以了，可实际设计上需要大量的更改，这样的例子应该很多。“领域建模”做得好，软件的适用性强，意味着这个模型也能快速地推广到其他用户，这样软件开发的利润才能最大化。
[该贴被flyzb于2010-10-15 00:14修改过]

恩，认同你的一些观点。不采用领域驱动设计并不一定是面向关系库设计。采用领域驱动设计是一个起初慢，但是越到后期越快的方式，这其实就是领域驱动很关键的一点，因为随着项目的发展，我们将对领域的理解，慢慢重构到了领域模型中，那么这个领域模型必将越来越能经得起考验。但是做领域驱动设计前期要做的工作很多，如果一个项目没有时间限制，没有上面给你的压力，即使这个项目是产品经理一时脑子发热想出来来的奇思妙想，你完全可以按照领域驱动设计去做，因为有时间，领域的概念你可以花很多时间去抽取，去积累，当然这种情况很少。所以我说并不是任何项目或者任何项目的任何生命周期里都适合领域驱动设计，也许有些项目上线后发现市场反应不行，后期都不做了，你前期花了那么多精力和时间搞出来的东西是不值得的，所以还是要有把握好领域驱动设计切入到项目周期的时机。

另外不要什么都领域驱动设计，要综合考虑其他方面的因素，比如项目周期，项目本身的逻辑是否复杂等，不要一味的啥都要来一把领域驱动设计，这样反而让领导觉得，你说领域驱动设计多好多好，怎么做了这么久第一期还没出来。所以为了让领域驱动设计走的更远，我们最好把握个度，这个度很重要，虽然我本人也一直坚持领域驱动设计，也在公司极力倡导领域驱动设计，但是要想让领域驱动设计真正运用到互联网项目里，我还需更加努力。

嗯。。表示理解。作为我们自己，首先是一种坚持。目前很多公司都很浮躁，这也是现实。

“好的领域建模应该具有柔性，能够伴随着用户一起成长”

楼主这句话说的太妙了，槽糕的项目总是因为缺乏成长能力而被遗弃，我们很多时候由于某些外在原因而只去考虑当前的需求，导致软件的生命周期有限。时间长了，貌似都已经称为习惯了，很少去考虑未来的发展变化，项目永远是项目，总实现不了从项目到产品的跨越。从这方面看我是真的很赞同领域驱动，但好像凡事绝对了都存在问题，如果老板是浮躁的，你也只能跟着浮躁，除非不混了。

[该贴被daihoujian于2010-10-15 13:02修改过]

所以在想使用领域驱动时，就得考虑时间的可行性了，而现在领域驱动一般都是过长的时间，如何才能减少时间呢，如 xmuzyu 所说的，具有相对稳定领域的应用开发，可以减少很多时间。

当然领域驱动是一个设计方法，并不是分析方法，当拥有一个不错的分析方法（例如四色），也能提高效率，而普遍状况都是缺乏一个有效的分析方法（很多人都是用传统思维，包括我╮(╯▽╰)╭，不过我在改了，有好的可以拿出来分享啊）。

“好的领域建模应该具有柔性，能够伴随着用户一起成长”，软件伴随用户成长的观点，很早以前就有了，问题一直也没有很好的方案，领域模型在这方面很有潜力。嗯~~~果然是一只潜力股~~~~