论业务领域知识比掌握技术更重要(从建模贴子切分出来)

我觉得这样空对空地讨论数据建模 vs 对象建模根本是毫无意义的，因为用户不会关心你的系统是OO建模还是数据建模，用户只关心你的系统是否能符合他的业务需求。

作为IT人员最重要的是要做到2点：
1. 关注用户的业务逻辑，建造符合用户需求的系统。
2. 清晰的系统结构，维护性强的代码。

这2点就够了，技术只是一种手段，在IT业技术永远是日新月异，我们重点要学的是domain knowledge，一个熟悉业务的coder才是programmer，否则，只是一个coder！

从原来的OFBiz讨论，变成了数据建模 vs 对象建模，离题太远......

OFBiz给我们提供了设计优秀的data model，提供了清晰的系统结构，可维护性强的代码，为什么不去学习吸收它，去使用它呢？

如果你觉得目前有其他open source的企业应用系统作得比它好的话，摆出来，我们来做比较看看。

    此处没有空谈，请你仔细看看。这里都是有实践作为基础的，如果不谈，只说明到处都是一言堂。

  对象驱动要做的也就如你上面所说的。

  我今天又遇到一个只认为自己喜欢的框架就是世界上最好框架的人。

     如果说可以作delegate我同意，但是XxxTimeRange本身即是集合，他应该具有集合的基本操作。交集，并集，非........都是集合本身的行为。

不知道别人的情况，我自己已经做过5，6个不同方面的业务领域，而且不知道将来会再做那方面的业务。而且领域知识就不日新月异了？
这倒引出一个问题，因为程序员是要把业务转化为代码实现，需要对业务熟悉，但是专业度很高的业务，比如财务，物流，仓库管理等等，都有无数的专家在研究，那么程序员对于业务应该熟悉到哪种程度？
Martin Fowler说，专业人员是更容易构建好的业务模型，他仅作为一个辅导者，教会这些专业人员如何描述业务模型。
还有目前国内程序员角色的细分的越来越明显了，处于不同角色的程序员考虑的和学习的方面也不一样了。
泛泛的讨论数据建模和对象建模的优略确实没有什么意思，应该更多的讨论如何选择，如何平衡。

用delegate应当有问题吧,如果真的是在远程环境下如果你是引用PO,则变成值传递,相当于把PO也传过来了.如果是动态获取远程引用(直接用hibernate做不到),那就相当于增加了远程调用次数.不过非分布式情况下,至少我是*经常*直接把PO传出来.如果用VO,而PO中的方法不会被业务层本身调用,我觉得可以只在VO里面加上你的业务方法,PO就不加那个方法了.如果两边都加,也可以考虑继承或者introduction什么的.我认为最佳的效果当然是分布式环境下直接用PO当VO,但是在很多情况下比较复杂,效果也不一定都很好.

    IMO，如果不更新领域知识，不能真正了解业务逻辑，你如何建立一个好的模型？ 专业人员建立这个业务模型？ 他能理解什么叫扩展，什么叫复用？或者说，他要理解什么是open-closed嘛？

   目前我所实践的系统看来，吃透业务逻辑，才能设计出真正达到可伸缩性强的所谓模型。而这个模型，都是程序员建立的。

   建筑设计师也必须知道，无论他的设计多么美丽，他的设计方案要在结构方面成为可能。建筑设计师同时必须掌握结构设计师的知识。好的建筑设计师往往也是好的结构设计师。
  
   一点浅见，眯眼。

我不是说空谈，我说的是”空对空“，因为数据建模和对象建模适用的系统不一样，从前面的讨论中看到大部分的观点都是拿对象建模的优点去压数据建模的缺点，拿实际的项目需求出来，比较做数据建模和对象建模各自的优缺点，总结开发过程中的经验，这样的讨论会更有意义。另外我的一个生产物料管理系统里面和其他系统的集成采用对象建模，而系统本身业务流程用数据建模，这样混用使用下来也蛮不错的。没有必要非要拿abc技术压倒xyz技术。:)



我想在这里的各位或许都有非常好的in house framework，要比OFBiz好很多，但是我强调的一点是：OFBiz是open source的企业应用做得最好的，不同意的话，举其他的例子出来，我们可以做研究，比较。你要学OO的设计，可以看它的framework的设计，你要学数据模型，业务流程，可以看它的业务实现，可以从开源的代码里面学到如何渔，而不是仅仅是获得一条鱼，何乐而不为呢？套用一下广告词：我就喜欢。:)。没有错吧？

此模型非彼模型：），我说的是业务模型，都是和业务相关的。
业务专家比你更知道哪些业务会扩展，哪些业务会复用，他根本不关心open-closed。业务的复用更有价值，也更难。这好像是现在很多公司的开发目标，业务中间件，或者业务基础件都是围绕这个目标来的。对熟悉业务的人员进行必要培训，利用业务设计器，类似于画画业务流程图就实现大部分业务代码，然后生成相关代码，系统就跑起来了。
不过目前还没有完全成熟的产品。金碟，用友，思维加速都在推，有兴趣的朋友，可以去了解了解。
这就更跑题了
这类产品也是需要开发的，都会有一套框架，并更加注意扩展性。

和用户沟通的能力是否增强了？对于预判用户可能做的需求改变的能力是否增强了？预判项目的风险，对于进度的把握能力，和工作伙伴交流沟通，对于这些不同业务领域共性的理解（人员，组织，权限）等等这些这些都属于domain knowledge。而且掌握了这些业务领域的基本概念，这些是不会变的。

业务确实很重要
不过我还是不认为写OS,appserver,database的家伙仅仅是个coder


"企业级应用系统"?ofbiz是无所不包的吗?至少他没有涉及的领域必然就有比它做得好的:)