领域模型设计的思考：存储过程与模型层设计的分离的弊端

这段时间在北京这边做开发，是在.NET 平台上的spring.net+NHibernate+SQL SERVER 2008的集成的开发。
由于是spring的技术，所以这个项目有很浓厚的MVC是缩影。我们现在的开发模式是这样：MVC模式三层都有我们A方这边的程序员开发，我们的查询业务基本上依赖于SP，SP由B方方面开发，但是由于需求做的不完善，以及B方方面对需求的理解的不完善，导致SP经常改动。但是SP的每次改动了之后，我们开发应用程序这边的程序人员却不知道，除非是这边的程序员去调试以前已经开发好的程序，不然基本上是很难发现他们修改了存储过程。而且，存储过程的修改，带来的不仅仅只是页面表现层的数据绑定的问题，在模型层的domain和dto很有可能都要随之改动。就算B方方面修改了SP第一时间通知了我们，我们修改相应的模型层对象，以及重新构造层与层之间的访问参数以及返回类型也是相当费时的事情。
这里并不是说领域模型的不好，面向对象的开发，以及更加全面深入的去了解自己所开发的域对象，这样当然是更好。但是就我们这个项目目前的开发方式和现状来说，效率是相当低下了。数据库是基础，SP是根基，SP的修改直接影响上层建筑，而SP的控制权却不在我们A方这边，B方是要完完全全的控制业务，我们A方所需要做的事情，就是按照他们的文档来开发，甚至都不用知道业务，纯粹是填代码的机械活了。还不如从一开始，就让A方来做设计工作（包括业务的设计和数据库的设计，我们A方并不是没有能力设计这个问题）。

你们这是项目管理组织的问题，和领域模型没有任何关系。业务的变动必然带来领域模型的变动。你们其实只是一系列存储过程的外观罢了。不是用了几个Domain对象就是领域模型了。这个系统的领域模型其实是用数据库表和存储过程表示的。
你们的问题在于两个团队根本无法协调。他们的变更带来你们的变更是必然，问题在于你们根本不知道对方的变更。加之你们没有持续集成，很可能变更了很久你们才知道，修改的时候对方也无法给你们支持，时间长了可能他们那边都忘了。
我的建议是你们两个团队组合成一个团队（虚拟的，相当于远程协同开发），起码要共享需求任务列表。每次变更需要你们两方面在工作前进行协调，确认各自需要调整的地方和需要消耗的时间。

认同楼上说的!另补充:

既然是基于.net的项目,且业务全写在sp里,那么用领域模型去开发成本明显就比基于表入口的模式要高了!直接使用ado.net抽象了DAO加个service层就好.

1.这个系统的领域模型其实是用数据库表和存储过程表示的。难道最基础的模型不是数据库？即使你说的真正的领域模型，就可以脱离数据库？即使你不用SP，但是你也觉得绕不过SQL或是HQL吧？
2.我们这里现在就是这样，SP那边的改动我们这边根本一点讯息都没有，只有当测试到这个页面的时候发现数据不对或是根本就不出数据的时候，跑到数据库一看，sp被人改了。关键是写业务的人在北京，写sp的人在韩国，我们有问题不能当面谈，还只能走文档的形式，一步步的提给他们再来解决。所以我们一直都是一个虚拟的团队，但是有两点阻止了我们的交流：1）地域；2）语言

你说的领域模型是larman提出的还是eric提出的？
我怎么感觉你这个跟领域模型无关？谁控制了业务谁就控制了领域模型

韩国人控制了业务  一般来说domain不由我们来写   必要的时候我们也只写dto