最近一段时间都在看ddd和up，个人感觉使用up进行项目的管理开发，运用ddd进行领域建模，在设计阶段，运用tdd进行驱动开发，这应该是一个比较理想的开发模式，但好的东西在项目的开发中不一定会得到充分的运用。
比如up中强调的迭代开发，细化阶段经过5-8次迭代，每次迭代3周，要完成确定整体需求的90%，完成20%左右的成品代码的编写，项目风险最高、最核心的业务的需求和设计已经确定并有部分实现，剩下的在构造和移交阶段去完成。每次一迭代中又是按照ddd进行领域驱动建模，通过tdd来测试驱动开发。但是在实际开发中，很多情况是客户并不知道他需要什么，需求十分模糊，甚至只有不到一百个字的需求，需求的不断深化和挖掘需要大量的沟通和时间，而这一点首先是客户不一定做到，在客户的传统思想中，你先拿出一个整体方案看看再说，也就是系统的需求分析文档，有了需求分析文档，再看看你的概要设计，等详细设计出来后，才给你打钱。客户需求的挖掘和up强调的迭代开发是吻合的，而客户的思维是见着东西才给钱又和迭代开发的每次迭代出一个可运行的产品相矛盾，因为客户没有更多的耐心，等你一点一点去捏泥人。我记得在一本国外大师写的书中提到过盖房子的故事，一个公司选两家设计公司给他们设计房子，第一家公司一去就拿来之前才做好的一个非常不错的建设方案，有成品、有图纸，看上去效果也不错；另一家公司没有给出图纸，也没有太多承诺，它要求看客户的建设场地和需求，根据客户的需求重新量身定做一套设计方案，确保设计出来的东西就是客户想要的东西。这位大师强调说，最后取胜的一定是后面一家公司，因为他把需求放到了第一位，相对而言风险更低，成功的机会更大，前一家公司虽然有一个不错的设计方案，而且有成品展示，但是别人认为好的东西，客户不一定就认为好，用在别处成功的东西，用在这里不一定就一样会成功，所以从这点考虑，这家公司必败无疑。
我很赞同这位大师的观点，但是在国内，似乎很多公司都会选择第一家公司为自己做设计，因为他们往往没有自己的明确的需求，很多时候很容易被一些先入为主的观念所左右，所以大多数情况下，他们很轻易的相信他们所看见的，而不一定是仔细考虑他们真正想要什么，这是一个十分突出的问题！
其次，迭代开发对团队的要求很高，它需要团队成员对涉及的领域知识十分熟悉，甚至是精通领域概念，这样才能在每次迭代中做到游刃有余，而这一点上有很多公司也是望而却步，他们常常会说：这东西看上去不错，但是我们不会去用！
再次，说一个具体的问题。就是对象和关系不匹配的问题，在设计领域模型的时候，我们从面向对象的角度去分析实体、值对象，分析关联，隔离领域、确定聚合，随着对领域的不断深入理解，我们会去不断的精华模型，去改善设计，是设计更加柔性，使结构更加合理。但在对象的持久化的问题上，很多时候我们不愿意去使用hiberante这样的ormapping工具，担心hibernate在某些方面（比如性能上），不如原生sql来得高效，多数情况是使用自己开发的中间件，对jdbc进行封装，对分布式数据进行一些处理，这个时候关系模型的设计显得越发的重要，有部分重要的业务甚至放到了数据库中去存储过程实现。关系模型和对象模型在粒度上不同，导致不匹配的问题比比皆是，最终选择了一个折中的方案，看上去成了一个类一张表的样子，在使用对象的时候，对象的导航也成了一件代价巨大的事情，因为没有了hibernate这样的ormapping工具，使得从数据库中查询来的数据无法自动封装成对象，这样对象模型中的对象导航就成了一副空架子，设计的时候虽然是面向对象的东西，但真正实现起来有逐渐回到了面向过程的老路上来，这种感觉十分痛苦！
如何解决上述存在的问题呢，这是最近一直困扰我的问题，请大伙谈谈自己的看法！