从Jive2到JiveJdon3看OO发展轨迹

简单了还需要人参与做什么呢？见我另外一个帖子"求建模意见及建议":

http://www.jdon.com/jivejdon/thread/32246.html

由于MDA和MDSD发展，业务专家（不懂软件 但对业务精通）借助MDA和MDSD工具直接进入原来属于软件人员的领地，也就是说：业务专家不但进行建模分析，也进行设计，最后借助MDA或MDSD工具生成软件人员认为复杂的Spring+Hibernate之类代码架构。

你问我未来软件人员的位置在哪里？两个：

1. 依靠面向过程设计那些旧代码苟延残喘。

2. 依靠OO思想，掌握机器不能替代的复杂软件设计编码工作。

软件人员和工人一样，也会遭受来自自动化流水线的挑战，下岗或转岗。这是必然的。

所以，如果软件人员还是以复杂简单来对技术挑三拣四，这就象计划经济时代的养懒了的工人，对自己工作吃苦怕累，最后，简单的工作也轮不到你软件人员来做，MDA或MDSD自动化工具（类似自动化流水线）已经替代你了，软件人员只能做复杂软件的工作。

所以，个人奉劝，无须以简单好用来要求现在软件技术，如果做到简单好用，也轮不到什么都不靠的软件人员来用，业务客户就可以直接借助MDA/MDSD工具直接完成软件实现了。

这些都是软件走向更加专业的一个标志。否则象国内现在什么人都可以转行做软件，一个专业如果是什么人还能做就不能称为专业，这些都是暂时畸形形象。

[该贴被banq于2007年07月18日 10:07修改过]

[该贴被banq于2007年07月18日 10:08修改过]

banq兄，

在实践中，要是按照DDD领域建模，从需求分析的领域模型，逐渐过渡到设计模型，一次次迭代，两种模型(类图)很难match，因为在分析阶段的model里面有方法，在真正实现时，都移到了DAO或Service里面，而DAO和Service是无状态的，Domain其实已经不是Domain，而是Entity（所谓贫血模型）。难道领域模型只用来做描述、理解、分析业务不能直接映射成代码实现？ 如果用hibernate,spring 等框架很难实现领域模型（用AOP静态织入勉强可以做到）,Spring+hibernate里面的业务本质也是Transaction Script方式（《Patterns of Enterprise Application Architecture 》。如果领域模型不能很好映射成代码实现，对编程有直接的指导意义，那领域模型似乎就高高在上，设计和实现岂不是脱节了？如果不能像ROR自然平滑实现DDD,那spring+hibernate等框架本质还是面向数据表的编程，只是这个数据表不是真正的表而是贫血的POJO，因为hibernate只是个data Wrapper，或者本质就就是.

这个问题又类似当初EJB争论，虽然EJB2.0不是很OO，但是如果使用得当，并不会产生传说中那么多缺点，当然Spring/EJB3更进了一步。

话又说回来，Spring+Hibernate使用DDD的平滑性是不如ROR，但是软件不只是由对象化分析设计开发组成，还由对象化组件拼装构成，Java世界这么多年已经发展了大量对象化组件，我们可以将它们作为构件来构建我们软件一部分，这个同样也很重要，特别是对于构建复杂软件更是这样，而Evans DDD的优点就是体现在复杂软件上。所以，我依然认为Java在对付复杂软件上更胜于ROR，Java是平衡的。

>在真正实现时，都移到了DAO或Service里面，而DAO和Service是无状态的，>Domain其实已经不是Domain，而是Entity（所谓贫血模型）。

Evans DDD已经将Service纳入模型概念，领域模型三个形式：实体模型 值对象和服务。无论存在形式如何，业务逻辑需要扎根在领域层（服务也分领域层和应用层）。

另外，我个人观点：不要被所谓贫血模型概念误导，这又是一个没有准确定义的概念，就象当初POJO一样。不是说将所有行为都放入领域模型就是胖模型了，Jive2就采取了胖模型，但是这样结果导致更多耦合和纠缠。

就是采取更优雅的通过AOP织入，我注意到有人开始将save等操作放在模型中，这个我个人认为不妥，save属于对象持久化，属于对象生命周期的管理维护动作，一个对象不能自己对自己生命周期进行管理维护，这其实是很正常日常生活常识。我们人都是由父母给予生命的，不可能自己创建自己，万事万物的生命都不是它自己创建的，或它自己来管理维护。

>难道领域模型只用来做描述、理解、分析业务不能直接映射成代码实现？

根据我的经验和JiveJdon3，基本可以根据Evans DDD来直接映射到代码。比如JiveJdon3中有大量帖子过滤，例如对HTML过滤，对特别关键字过滤等等，这些都属于论坛这个功能业务，所以，应该放在领域层，但是又不能直接在代码形式放入ForumMessage这个模型中，这时就可以通过Decorator等设计模式来巧妙实现。

>从需求分析的领域模型，逐渐过渡到设计模型，一次次迭代，两种模型(类图)很难match。

只能说模型图逐渐复杂细化，设计模型更加细化，是随着我们对需求认识的不断深入的产物，这个不断迭代深入的模型图才应该是唯一的模型图，不存在两种或几种模型图。