Spring带来了什么？OOD学而无用

Spring没有提供OOD的额外帮助，所以Spring让OOD学而无用？行呗，我们都是拍脑袋的
你可不可以不要一直变换你的观点，前面几个月一直说Spring里面用不了OOD，然后变成Spring里面用不用DDD，最后变成Spring对DDD没帮助，为什么还要用，还容易误导开发人员。。

总结一下你最后的高论： 构建Domain很困难，需要设计，但是Spring太方便使用过程化了，所以它对DDD坏处非常大。。。按照这逻辑，我可不可以说 Servlet API把处理用户请求的线程封装得太好了，所以他让多线程编程学而无用，伤害太二了。

怎么在Spring里面用DDD，方法很简单，你的领域模型怎么聚合 与 Spring无关，你可以按照以前的设计，引入Factory、Builder去构建；而你的持久化实现这些东西，可以用Spring来注入；前面我也说了，Spring不是一个DDD框架，而只是一个IOC框架。 前面还有句话说的很好，OO不是目标，而是手段；用不用DDD是你设计上的选择，跟你用什么框架是没关系的，你说一个IOC框架阻碍了你DDD，这不是搞笑嘛。

建议楼主 去看看  《J2EE without EJB 》。
spring其实某种意义上就是简化的容器。

“Spring对DDD没帮助”这是你说的不是我说的。

我的观点：

1.用spring的web项目不用OOD.
2.Spring本身主要用在过程化的web开发中，不支持OOD.
3.深入的OOD知识在spring的web项目中用不到。

在你看来引入Factory Builder就是OOD了。还是去看这个吧，能看懂再回来发言吧：
ps: OOD扫盲http://www.iteye.com/topic/1129283#2388708

楼主 说得太绝对了。

只能说简单的 web访问数据型应用 用不到ood。
复杂的应用还是可能用到的。
工作流， 网络管理。
而且随着html5发展，基于web的设计工具也逐步出现。

比较复杂的 网上商店，也是需要合理的ood，才能做一个方便扩展的架构。适应各种 优惠活动。

看不懂人话，就会抠点词汇的人真头疼； 拜托你不要因为别人一直没反驳你的吐槽，就认可你在OO上可以随便鄙视别人；我用Factory、Builder的语境是创建领域模型，非聚合根的对象创建过程，在工厂中创建不是很常见吗？ 脑残。

是不是需要OOD, 是你的业务模型决定的。。 你接触过的垃圾模型，基本上每个实体就是聚合根，加入一下持久层就完成了，那你当然被Spring取代了。第一次听人说，是不是OOD是框架决定的，真是OOD大神啊。你喜欢叫别人看垃圾帖子，麻烦你也去看看企业应用架构模式，里面说到了使用领域的时机在于 业务规则的复杂多变，涉及复杂的计算和衍生，另外就是团队设计和掌握领域模型的能力。。 Spring不能阻止任何团队使用OOD，它是团队对软件设计的结果，而不是设计的因素。

1.的确看不懂你说的话。我之前针对你贴子中的技术问题，你也不回答。你只会含糊其词吗？

我向你请教了。

什么是非聚合根？为什么非聚合根要用Factory和Builder创建？在什么样的应用中常见这种用法？

呵呵。

别玩你不理解的名词了，这不比骂人的话更有用。要是真懂，就拿个实际的例子出来。OOD致少得有建模结果和代码吧？你这么牛X，在spring里边弄一个出来。何必和我说些忽悠人的话呢？


2.我没说过OOD是由框架决定的。
 
  你这人理解能力有问题。我说的是spring在业界大行其道，使得事务脚本成为了主流，自然就用不着OOD了。
 
  之前还说“spring对OOD没有帮助”是我的观点。这也是你说的话。

  你有点乱啊。

  这是你说的：“是不是需要OOD, 是你的业务模型决定的。。” 你记住，别一会又变成我说的。

  请问：业务模型是个啥样子？怎么判断需要OOD的和不需要的？举个例子吧？
 
  举不出来，就别说话了。有意思吗？


3.即然说到 企业应用架构模式 我就摘几段送给你：


以下是《企业应用架构模式》中的内容

第八章的内容：
领域模型也有其缺点。最大的缺点就是难以学会如何使用领域模型。.....第二个缺点就是与数据库的连接....

第九章的内容：
首先，将领域模型映射到数据库通常有一些难度，这让我有点害怕，所以并未提供一个这样的示例。
领域模型的问题之一是与关系数据库的衔接。在许多时候，这种方法中的数据库就像马蜂窝一样，没有人原意触及。

这是你说的：“怎么在Spring里面用DDD，方法很简单……”

我猜你的自我感觉比Martin Fowler好！

我只回答第三点，对前两点脑残问题不予置评：

首先，将领域模型映射到数据库通常有一些难度……首先，将领域模型映射到数据库通常有一些难度……

这里说的领域模型到数据库映射的难度，是指 领域模型 和 数据库表结构 映射的难度，而不是指业务层和数据访问层的关系很难设计，实际上Spring做的是依赖关系还是做了映射工作一目了然；既然你这么喜欢评价别人，不喜欢讨论问题，我也送你一句吧，别baidu出一本无版权电子书，翻出两句，就假装领会到精神了，还拿来鄙视人，我看你才是比Martin Fowler感觉还好啊。

我对英文.....
拼写100行能错20次.....
没有代码提示写hashmap....的key 不过sublime很好用.

OOD还真不是用来解决意面问题的
意面问题是面向过程解决的.

OOD是为了设计出隐藏实现的
例如客户需要一个ipad应用 可以实现 页面滚动   页面弹出
那么你写需求设计时就要把滚动弹出
分别写在不同的模块中

而不是实现一个万能页面动画模块 加一堆参数列表.
虽然里面可能是调用同一个万能页面动画模块 加一堆参数列表.
因为它在脑子的模型不是.同一个模型.


好处是所有的相关人都知道你设计的是什么
(所有的参与者包括我们的老板,客户,什么都不懂的新手开发者)
而不是 我设计了一个二叉树的左右数来实现无级菜单功能 .(虽然这你是这样实现的.)

让所有的参与者都了解的文档才是好文档.
忽悠的文档很多比如oop ood 高科技,信息化....我常常看的都是这类

OOD说白了就是给小白能看的懂的设计方式.
三层贫血还真不太算是OOD
顶多是框架指定方向的开发
与使用cms作网站一样不是开发,不是设计,
只是在他的限制帮助下
可以完成有限种可能性,
并这些可能性能达到凑合的水平.

你可以参考一些代码生成器
那里面利用了spring的限制
完成了从建库,
到页面实现的一系列工作
如果你有时间可以写写这部分代码
纯crud单表增册改真不需要设计

对于核心业务逻辑
比如我们项目中在改造之前
五千四百多行的一个循环计算
使用了一个业务员的分类创意
很方便的重构了外代码.
之后五千多行的代码中 巨多分支判断都被 去除
再加上把 一方块 一方块的set 变成了工厂方法
现在只有 300 行代码了
如果没有OOD业务员也不会明白我们作的所有的工作
与他们正在处理的工作是一码事
知道也没办法使用他们的经验
在我们处理过程中
(当然也是由于我们的流程与他们的流程一致的)

我觉得OOD其实 还是最基本的  分解问题，隔离问题，最后解决简单问题 的概念。
而命名空间，类，接口，只不过粒度的不同级别的映射而已。

类的实现到最后，不还是各种函数的集合么，只是有些参数不用从参数列表里取了。
   

我个人认为软件开发应该务实而不应该上升到意识形态的高度：

A:我的操作系统在桌面市场占有垄断地位
回答：你这个系统不是用OO语言开发的

B:我的操作系统是开源操作系统的代表，也是占有率最高的手机系统的底层
回答：你这个系统不是用OO语言开发的

C:我的论坛是国内业界的标准
回答：你这个系统不是用OO语言开发的

D:我的电子商务平台在国内占有率最高
回答：你这个系统不是用DDD设计的

DDD如果真是银弹，为何没能被广泛推广？
不要老是埋怨开发人员素质不够。
如果DDD在项目开发上有实实在在的效率和维护性优势，且能适应各种具体的工程环境，比如:Web、DB，自然会吸引企业和开发人员去使用。

OO和DDD是软件开发的工具，而不是软件优劣的衡量标准。

如果在架构师角度，对于DDD的执着还可以理解。如果是从项目经理角度，这个根本不会是个问题。