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

这段时间在北京这边做开发，是在.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方并不是没有能力设计这个问题）。