我还是不怎么明白“领域驱动设计”

我觉得ddd最有用的地方是以bo来描述业务，如果按照数据库驱动设计、非ddd的方式， 也许很多业务逻辑都分散到了 service、 controller 或者sql中，真正代表业务对象的东西被贫血的model代替了。
这样的后果重领域上看，业务行为无法内聚到相应的业务对象上，比如一个账户业务对象（account）可能有注销，账户欠费通知，转账 的行为。
如果不用ddd，这些行为也许会被分散到n个service里，而没有集中在account上体现。
别人拿着代码，如果不去分析service或者controller，就根本无法从贫血的account上看出 账户究竟能做些什么。
比如，目前我负责的项目就遇到这种问题，大量的业务行为被集中到一个service里，甚至有些不知道该放在哪里的业务行为，也被放到service里了，导致service无比巨大。。可读性，维护性极其差，这就是没有根据领域对象分割职责归属导致的结果，

使用ddd后，因为业务职责清晰划分到对应的bo里，自然就能针对某个BO进行扩展了，而不会影响其他的bo或service，提高了系统的可扩展性，
同时，系统可读性大大增强，具有很强的自我描述性，通过读bo，就能知道某个业务对象能做什么，怎么做的。dci更进一步，引入了场景，角色，将实际的业务场景更清晰的显示出来，直接重系统代码上上就能知道系统涉及的各个业务场景，以及在业务场景下，有那些角色参与，这些角色是怎么组合起来实现业务的。
总而言之，我觉得非ddd设计时，系统所有业务逻辑的代码划分是团散沙，只能通过界面操作，controller 来驱动业务，并不能系统架构上真正的体现业务。

ddd的另一大好处是缓存。。但我现在始终无法脱离数据库的影响。
[该贴被berserk于2012-02-02 11:54修改过]

非常谢谢你的回答：
我是初学者，问的问题很低级，希望不要建议，我最近一直在学习，在观看关于DDD的资料，文档也在看，我看了总是觉得DDD就是你对一个行业的业务理解情况，在这里我说一下我们公司的项目为例：
我们公司现在在开发一套“金融产品”，我进公司半年，我反正觉得我们公司的设计也不说好，也不说差，反正很乱，中国很多软件公司都这样嘛！就拿我这个项目来说，怎么以DDD去理解和分析我们的项目，就拿“领域”来说，要从领域来分析我们的项目，那你肯定一定对我们金融的一切业务很了解，你才敢说领域，我不知道我说得对不，你明白了领域，你才可以从面相对象的设计角度来设计我们的项目，才可以很好的设计我们的业务层。。。。。这样才可以得到所说的DDD的好处和优点。那一句话，就是要明白你开发软件的行业的业务（就是所说的领域）对吗？
你说的，现在项目中，一个service可能有很多代码，这个我给你一样身有感触，有些代码根本不是service的代码，也写在里面，
我还有一个问题，就是关于DDD可以很好的解决需求变更的情况，我觉得不管你怎么样设计（用不用DDD），需求变更都很麻烦，我们公司一样，现在要修改一个功能，改动量很大，很麻烦，完全不灵活，是不是以DDD来进行设计分析（前提是很好的理解金融的业务领域），那样设计出来的项目到时候就很灵活，因为这是建立在DDD领域设计的基础上的，如果是这样，我基本明白，不是这样，我还是很不明白？

老外有句话：As a programmer, it is your job to put yourself out of business. What you do today can be automated tomorrow.作为一个程序员，如果你脱离业务，那么你今天的工作明天就能被自动化实现。

DDD等OO方法技术实际是一种纯自然方式，而使用数据库等有自身约束条件的分析方法，会妨碍对需求的自然分析和设计，比如数据库是表达一种静态二维数据，那么动态的怎么办？只能记录动态的结果数据，而不能表达动态本身。

技术工具自身特点会妨碍对需求的自然分析，不妨碍需求分析的工具最好自身无特点，是一种“无”，但是“无”又比较难以让初学者掌握，你得给他们一个有形的东西他们才容易学，这是世界奥妙之处。

由于DDD等是一种方法思路，而不是有形的产品等，所以，自身不会对需求的变化产生阻碍，需求变化，领域模型设计和代码改一下即可，由于有OO等边界封装，这种修改不会无边界的蔓延扩展开来，造成一发动全身的糟糕局面。而且随着软件规模的复杂，开发和维护工作量总是线性增加，使用其他技术工具就会层现陡峭上升。

[该贴被banq于2012-02-02 17:34修改过]

谢谢banq的回答：
我现在心里很高兴，我觉得我有那么一点明白领域的意思了，是的，它就是一个思想和无形的对象，它的最能体现（反射）事物特征的设计，是自然的，没有什么限制的分析，才可以发挥后期开发的最大力量。不知道理解对不？

是的，自己不会限制分析，无才生有。打个比喻：看电影时，前面有人站起来挡视线，你站起来去劝阻他坐下来，你站起来其实也是挡别人的视线，当你在解决问题时，不要让自己再制造新问题。

对，是这个问题，我觉得要形成一个重要的领域设计思想的非常不容易的，有领域---抽象模型---代码，这样的几个过程要用领域来分析，在我们抽象模型和代码映射的过程中，可能对于领域来说，这样抽象是非常的好，但是在对应代码实现的时候就不一定能很好的实现，这样代码设计也不符合好的软件项目标准，我非常清楚，领域---抽象模型，但是抽象模型---代码实现，还是有那样一点生硬，不自然，看似没有什么关系，其实关系很紧密。不知道这个过程怎么考虑？？？

这就需要涉及到其他更细致的方法，比如DCI或事件等，推荐你读一下：机器人分析设计案例，这是我以机器人这个业务为案例，从分析设计直至代码实现过程，可帮助你思考。

道友关于DCI的理解

代码实现时另外一个主要考虑就是性能，见这个讨论：高并发设计

[该贴被banq于2012-02-06 09:20修改过]

就算不使用领域驱动设计，就算不使用OO，你也应该对你的业务有清晰的认识啊，不然你怎么保证你写出的程序是正确的？是符合用户需求的？

恰恰相反，领域驱动设计反而适用于对业务并不熟悉的情况，通过逐步重构，逐步精华，来“挖掘”出逻辑。