|
锁定老帖子 主题：Spring带来了什么？OOD学而无用
精华帖 (0) :: 良好帖 (9) :: 新手帖 (19) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2013-04-17
鱼言风语 写道 如果在架构师角度，对于DDD的执着还可以理解。如果是从项目经理角度，这个根本不会是个问题。 即使是 架构师，执着 也不可以理解。 架构师的重要的任务是找到 团队 能够共同使用的技术，而不是因为自身的精神洁癖 选择某种技术。 （me算公司的架构师 虽然最近 被郁闷于根本不能选择合适的技术。  ）
|
| 返回顶楼 | |
|
发表时间：2013-04-18
最后修改：2013-04-18
鱼言风语 写道 我个人认为软件开发应该务实而不应该上升到意识形态的高度：
A:我的操作系统在桌面市场占有垄断地位 回答：你这个系统不是用OO语言开发的 B:我的操作系统是开源操作系统的代表，也是占有率最高的手机系统的底层 回答：你这个系统不是用OO语言开发的 C:我的论坛是国内业界的标准 回答：你这个系统不是用OO语言开发的 D:我的电子商务平台在国内占有率最高 回答：你这个系统不是用DDD设计的 DDD如果真是银弹，为何没能被广泛推广？ 不要老是埋怨开发人员素质不够。 如果DDD在项目开发上有实实在在的效率和维护性优势，且能适应各种具体的工程环境，比如:Web、DB，自然会吸引企业和开发人员去使用。 OO和DDD是软件开发的工具，而不是软件优劣的衡量标准。 如果在架构师角度，对于DDD的执着还可以理解。如果是从项目经理角度，这个根本不会是个问题。 国内大多数的项目难度真的只有CRUD 复杂业务逻辑 三五个项目中看不到一点点 多数客户需求是, 看到XXERP没有?好的我就要那个, 最重要的是按钮上的字体也要与那个一样...... 遇到这样的项目别扯蛋什么OOD OOP c-C c-V 才是正道 |
| 返回顶楼 | |
|
发表时间：2013-04-18
最后修改：2013-04-18
抛出异常的爱 写道 鱼言风语 写道 我个人认为软件开发应该务实而不应该上升到意识形态的高度：
A:我的操作系统在桌面市场占有垄断地位 回答：你这个系统不是用OO语言开发的 B:我的操作系统是开源操作系统的代表，也是占有率最高的手机系统的底层 回答：你这个系统不是用OO语言开发的 C:我的论坛是国内业界的标准 回答：你这个系统不是用OO语言开发的 D:我的电子商务平台在国内占有率最高 回答：你这个系统不是用DDD设计的 DDD如果真是银弹，为何没能被广泛推广？ 不要老是埋怨开发人员素质不够。 如果DDD在项目开发上有实实在在的效率和维护性优势，且能适应各种具体的工程环境，比如:Web、DB，自然会吸引企业和开发人员去使用。 OO和DDD是软件开发的工具，而不是软件优劣的衡量标准。 如果在架构师角度，对于DDD的执着还可以理解。如果是从项目经理角度，这个根本不会是个问题。 国内大多数的项目难度真的只有CRUD 复杂业务逻辑 三五个项目中看不到一点点 多数客户需求是, 看到XXERP没有?好的我就要那个, 最重要的是按钮上的字体也要与那个一样...... 遇到这样的项目别扯蛋什么OOD OOP c-C c-V 才是正道 也没你说的这么不堪，有的项目业务也很复杂，但那种复杂不是DDD能搞定的 |
| 返回顶楼 | |
|
发表时间：2013-04-19
我觉得项目是否有生命力不是它复杂或者简单，而是能否让用户发挥他们的想象力来做事情。
|
| 返回顶楼 | |
|
发表时间：2013-04-19
最后修改：2013-04-19
鱼言风语 写道 也没你说的这么不堪，有的项目业务也很复杂，但那种复杂不是DDD能搞定的
违反常识。 抛出异常的爱 写道 鱼言风语 写道 我个人认为软件开发应该务实而不应该上升到意识形态的高度：
A:我的操作系统在桌面市场占有垄断地位 回答：你这个系统不是用OO语言开发的 B:我的操作系统是开源操作系统的代表，也是占有率最高的手机系统的底层 回答：你这个系统不是用OO语言开发的 C:我的论坛是国内业界的标准 回答：你这个系统不是用OO语言开发的 D:我的电子商务平台在国内占有率最高 回答：你这个系统不是用DDD设计的 DDD如果真是银弹，为何没能被广泛推广？ 不要老是埋怨开发人员素质不够。 如果DDD在项目开发上有实实在在的效率和维护性优势，且能适应各种具体的工程环境，比如:Web、DB，自然会吸引企业和开发人员去使用。 OO和DDD是软件开发的工具，而不是软件优劣的衡量标准。 如果在架构师角度，对于DDD的执着还可以理解。如果是从项目经理角度，这个根本不会是个问题。 国内大多数的项目难度真的只有CRUD 复杂业务逻辑 三五个项目中看不到一点点 多数客户需求是, 看到XXERP没有?好的我就要那个, 最重要的是按钮上的字体也要与那个一样...... 遇到这样的项目别扯蛋什么OOD OOP c-C c-V 才是正道 使用OOD的动机一方面是业务逻缉复杂。 另一方面，还有一个普遍的情况： 在早期没有框架时，架构工作是要开发者自已搞定的。这时，框架上的设计是需要OOD的。因为spring等框架替开发者做的事，需要开发者自已设计。 而现在的情况和以前有所不同。上来就是三层贫血，不需要在架构上动脑了。 在这样的环境下成长的程序员，是没有动力学习OOD的。 |
| 返回顶楼 | |
|
发表时间：2013-04-19
最后修改：2013-04-19
gdpglc 写道 鱼言风语 写道 也没你说的这么不堪，有的项目业务也很复杂，但那种复杂不是DDD能搞定的
违反常识。 抛出异常的爱 写道 鱼言风语 写道 我个人认为软件开发应该务实而不应该上升到意识形态的高度：
A:我的操作系统在桌面市场占有垄断地位 回答：你这个系统不是用OO语言开发的 B:我的操作系统是开源操作系统的代表，也是占有率最高的手机系统的底层 回答：你这个系统不是用OO语言开发的 C:我的论坛是国内业界的标准 回答：你这个系统不是用OO语言开发的 D:我的电子商务平台在国内占有率最高 回答：你这个系统不是用DDD设计的 DDD如果真是银弹，为何没能被广泛推广？ 不要老是埋怨开发人员素质不够。 如果DDD在项目开发上有实实在在的效率和维护性优势，且能适应各种具体的工程环境，比如:Web、DB，自然会吸引企业和开发人员去使用。 OO和DDD是软件开发的工具，而不是软件优劣的衡量标准。 如果在架构师角度，对于DDD的执着还可以理解。如果是从项目经理角度，这个根本不会是个问题。 国内大多数的项目难度真的只有CRUD 复杂业务逻辑 三五个项目中看不到一点点 多数客户需求是, 看到XXERP没有?好的我就要那个, 最重要的是按钮上的字体也要与那个一样...... 遇到这样的项目别扯蛋什么OOD OOP c-C c-V 才是正道 使用OOD的动机一方面是业务逻缉复杂。 另一方面，还有一个普遍的情况： 在早期没有框架时，架构工作是要开发者自已搞定的。这时，框架上的设计是需要OOD的。因为spring等框架替开发者做的事，需要开发者自已设计。 而现在的情况和以前有所不同。上来就是三层贫血，不需要在架构上动脑了。 在这样的环境下成长的程序员，是没有动力学习OOD的。 OOD是由于业务逻辑变化可能性多. 需求设计灵活 可以使用的实现方式参差不齐 切分功能模块之后 交流理解时间长 详细设计之间接口磨合困难 交流成本隨人数成指数倍的增长 百人以上的团队想要开发一个软件 光用嘴说得说死 当设计与开发之间有三层级时几乎是无法把意图正确传达的给开发人员的. 所以ood 在设计阶段就像XP中的隐喻一样 他把需要开发东西 拟人 拟物 拟事件 用最快的方式把必要的细节 隐藏在比喻之中.... 对一个没见过老虎的人说 一只大约500斤 重的大猫 (头,身 脚 尾 颜色 都隐藏了) 对一个没见过ipad的人说 一只四个iphone屏幕大小的手机.....但它不能打电话.... (形状 按键 颜色 都被隐藏了) 在设计时 会说这个项目 有一个工作流 有一个短消息 有一个CMS信息发布 有一个商城 有一个论坛 有一个CRM客户关系层级显示 有一个统一登陆 有一个时时聊天系统 这其中 短消息有可能只是论坛的版面改改就可以 CMS信息发布可能 在工作流中也有 同样的 流程发布 统一 登陆 与客户关系 时时聊天系统 有关联 CRM 客户关系与 商场的定单系统相关连 ..................... 分析 之后 把需求破碎之后 变成开发用的模块 减少开发量 减少模块之间的接口 减少模块之间的依赖 ..............业务 还会一点点的增长 比如把库存系统加入一个ERP 进销存加入一个 定单跟踪 跟踪里面上一个GS地理定位 保密贵重产品需要审批 仓库里加一个摄像头 使用net meeting 模块 电话语音答录 编辑进CMS中去 接线员工作量统计 接线员任务调度 加到CRM中去 没有OOD的设计 想把这些东西柔到你的系统中 你要说好几个小时吧..... |
| 返回顶楼 | |
|
发表时间：2013-04-19
最后修改：2013-04-19
这帖子讨论的还真久........
先说 DDD , DDD 不止有 domain. 还有 Factory , repository . 一段话: MF（MartinFowler）曾经提出有名的贫血模型或失血模型，他认为实体模型对象中只有弱行为setter和getter方法，没有真正行为，好像缺少血液的人，不和谐了，而Eric认为，在DDD中，领域中的一些概念是不能作为模型中的对象来处理的，如果将这些功能概念强行加给实体对象和值对象，会破坏模型中对象的定义.我们的DDD项目中都是以失血模型存在着，所以，Eric呼唤：建模专家必须懂得实现，懂得软件技术。 首先,domain不可能包含所有的行为.比如对象的创建是 Factory 来做的. 然后将这个 Domain 有什么行为,放在 Domain 里. 我也有看 LZ 这个 http://www.iteye.com/topic/1129283#2388708 帖子. 这个设计是没问题的,但没有想到实现时遇到的问题. 再有一点不敢苟同. { robin有过论述。 原贴：http://www.iteye.com/topic/281289 内容： 如果你用的是Spring，没啥说的，必须贫血，你想充血也充不起来； 如果你用的是RoR，也没啥说的，直接充血，你想贫血也未必贫得下来； } 这篇文章也说了,贫血的Domain 不是 spring 造成的,是 Java 实现充血的 Domain 比较麻烦,而且并不美好. Spring 是可以做到的. 我觉得LZ最大的分歧在于OOD 的话. 把Domain 的行为写在 Domain 里才算是 OOD. 设计的时候可以看作 Domain 去设计,实现的时候也可以写在 Service 里. 一个 Domain 对应一个 Service. 仅此而已. 其实把行为写在 Service 里是受到了代码实现时的限制,以及一些其他的原因. Domain 过大了,太大了.想通过 Domain 来控制行为并不比 Service 有效.不合格的程序员可以在 Service 里乱写方法. 难道在 Domain 里就不会乱写么?review domain 和 review service 差别在哪里? Controller 调用 Service , Service 调用 Repository , 这样实现是可以满足很多情况. 流程简单,而且很多学校培训机构都是这么教的,简单有效既是好的. Domain 小了, 对应这数据库各个字段. 比较清晰.否则混杂这 set/get ,以及个各种行为方法,有点恐怖的. -------------------------------------------------- 上面啰嗦了半天,就是想说. OOD 去设计Domain, 并可以将 Domain 的行为放 Service, 一个 Domain 对应一个 Service . OOD 的设计能力好, 那么Service 重用度,可扩展性, 也会好. 如果开发人员设计能力不够, DDD 一样写不好, DDD 是依赖 Domain 的,糟糕的 Domain 会导致更恶劣的影响.Domain 里面的行为一样没人会去重用. 嗯嗯. 最后一句 OOD 和 Spring 一毛钱关系都没有. Controller --> DomainService --> Repository<Domain> 这样的方式,一样可以 DDD . |
| 返回顶楼 | |
|
发表时间：2013-04-19
suene 写道 嗯嗯. 最后一句 OOD 和 Spring 一毛钱关系都没有. Controller --> DomainService --> Repository<Domain> 这样的方式,一样可以 DDD . 我讨论的不是纯技术的因果关系。 把思维放到技术选择上。这时spring在过程表达上的优势会排拆OOD。 |
| 返回顶楼 | |
|
发表时间：2013-04-19
最后修改：2013-04-19
suene 写道 Controller --> DomainService --> Repository<Domain> 这样的方式,一样可以 DDD . 你这个和 action service dao 有什么区别？这不还是事务脚本吗？ |
| 返回顶楼 | |
|
发表时间：2013-04-19
gdpglc 写道 suene 写道 嗯嗯. 最后一句 OOD 和 Spring 一毛钱关系都没有. Controller --> DomainService --> Repository<Domain> 这样的方式,一样可以 DDD . 我讨论的不是纯技术的因果关系。 把思维放到技术选择上。这时spring在过程表达上的优势会排拆OOD。 哦? 是么? 呵呵. |
| 返回顶楼 | |
