有关领域对象

传统的方式确实解决了大量的复杂的业务方式，不过要说他们是可重用的话，或者说重用度高的话，我是反对的。事实上我接触过的一些实际案例，很多基于数据库的业务实现，他们实现了很复杂的业务逻辑，并且性能还可以，但是特别臃肿，经过多次修改，已经非常混乱，基本没有可重用度，而且往往公司只有一两个极度熟悉该系统的人具备修改的能力，任何其他人都不敢去动。不管是增加功能，还是去部署，都是让人提心吊胆的事情。

你不能绝对说这些代码肯定不能重用。你也不能理所当然地认为所有软件公司工作都做得那么差。
问题是对于这些公司来说，有些底层的工作他们已经做过了（可能他们还自以为做得很好），他们现在关注的重点已经放在了比较高的层面。他们并不情愿永远做这些底层的工作。遗留的系统对于他们可是立身之本。你要是跟他们说：你们那些东西都是垃圾，应该毫不犹豫地抛弃，他们毫无疑问会把你打出门去。但是你如果这样对他们说：你们以前的那些工作还是很有价值的，但是因为这个那个设计方面的问题会影响这些代码发挥更大的价值，有必要采用这个那个重构方法或者重新设计，这样将给你们带来更大的价值，使得你们可以更容易地应对各种变化。那么他们一定会很尊重你的意见，并且把你奉为上宾。

你有志于做咨询。做咨询沟通能力是非常重要的，很多时候并不是你的观点错误，而是你的表达方式存在着问题。

奇怪的很，你们两个看见的遗留代码是一样的吗？


代码重用性，又不是靠OO保证的，是靠经验和用心重构保证的。这有什么好多说的。

庄的观点是正确的，实际上我认为 Transaction Script 也是可以达到一定程度的重用性的，但是肯定没有 Domain Model 高，也没有 Domain Model 灵活。这个我们 3 个人都是没有分歧的。我说得其实是一个现实存在于很多公司的现状。

一个类对应一个表，类的每个成员变量对应一个表字段，不包含任何业务代码。
不知道这样的类应该称为什么？

OO
好的设计可以很好的重用。
谁可以重用？
一个刚接手系统的人肯定达不到重用的要求，它根本不理解设计以及业务实现的原理。

我觉得在复杂业务的重用上，还是建立在对系统十分熟悉的基础上的。重用更多的是指修改业务规则，同一领域内的业务逻辑部分的部分重用。

至于说OO的具体体现，看看哪些支撑庞大业务核心运作的类的命名层次，接口实现层次就大概可以看出整体系统的OO设计如何如何了。

其实我看到的现状就是现存的基于数据库系统已经非常脆弱了，这种脆弱指的是可维护性，可扩展性。除了某几个特别熟悉的人之外，其他人都不敢去动，而这个人一旦休假，整个系统就瘫痪。我见过有3个公司都是这种情况了。

事实上，往往是公司的领导从他开始就有这种对系统进行改造的愿望，希望用先进的对象化的方式来改造或者重写现在的系统，解决这种问题。

虽然很多公司投入资金和人力去重写整个系统的尝试失败了，但是往往是因为他们对对象建模这种开发方式和技术水平的掌握不够导致的，但不管怎么说，很多公司还是意识到了传统方式的弊端和崭新的方式的优势。

robbin讲的情况是非常普遍的，我基本上可以断定一个业务逻辑比较复杂的系统全部实现在数据库中（或SQL语句中）加上TS的做法是非常难以重用的

一般公司里面只有1-2个人才敢改，系统越庞大，感改的人就越少，改了以后也是心惊胆战的，这种系统我看到得实在太多了

OO在这方面是一个极大的提升，因为OO让你必须更加模块化

存贮过程可能实现一定的模块化，特别是Oracle的SQL语法带有某些OO的能力和机制，但毕竟不能和OO编程语言相比，拿到这类传统系统，我第一步不是去修改业务逻辑，而是用更加模块化的方式重构Oracle的存储过程，接着再考虑领域模型封装这些存储过程，然后再慢慢把这些逻辑移出数据库，这样的改造我做过两次，如果不是Oracle的话，恐怕只有重写一途了

说道Oracle的存储过程，不知道我下面的话是否过于鲁莽：
现在大部分银行核心系统的开发对于Oracle的存储过程使用到了极致！
不知道，这是否是为了即可以快速适应复杂业务，又可以不影响执行性能的唯一途径。据我所知，这些开发方法就是外包公司项目组一般采用的银行核心业务系统开发守则之一。（包括深圳的某甲××文公司）
说错了，请开骂！不好意思。

这很正常，因为银行的遗留系统用的都是这种方式，并且OO的开发成本在早期来看是相对较高的（你需要比存储过程更多的抽象模型）

想起一个故事，我大约在三年前去一个公司做技术负责，当时有一个项目已经运行了1年左右，但是不断的修改导致原先的业务出现了很多问题，大家都觉得头都大了，该了这里，那边出问题，改了那里，这边出了问题，原先写存储过程的人有几个也不再了，结果大家对着一系列中间表和表里面很多莫名其妙的标志发呆，拿来原先的设计文档和数据词典一看，很多都对不上。而存储过程代码本身的表达能力又非常有限，很少有抽象、一致的概念。例如，标志其实使用来代替OO子类的，中间表常常用来表达对象之间的复杂关系等等。业务逻辑实现通常是单片的过程代码，而无法用揭示意图的可覆盖的方法来表示。

我看了原先的系统后发现居然每一个业务，不管简单还是复杂全部都是用存储过程实现的，分析他们的业务以后，我提出基本上不需要几个存储过程，结果把项目经理吓了一跳，没有存储过程怎么写程序？

实际上我看到过的系统有非常多的是用这种方法实现的，不管是银行系统、ERPx系统、公安系统，而实际上正是这些系统才比一般的系统具有更加复杂的逻辑，才有更大的规模，才是OO大展身手的地方，可惜由于从业人员的水平（她们的业务水平比较高，因此在技术上也有了相对多的说话权）、传统系统的遗留和OO早期的复杂性导致了正是这些系统在国内处于较低的技术水平。