这里同样延伸出另外一个问题:数据库设计问题，数据库是否需要在项目开始设计?
如果我们进行数据库设计，那么就产生了一系列问题:当我们使用Hibernate实现持久保存时，必须考虑事先设计好的数据库表结构以及他们的关系如何和业务对象实现映射，这实际上是非常难实现的，这也是很多人觉得使用ORM框架棘手根本原因所在。
当然，也有脑力相当发达的人可以 实现，但是这种围绕数据库实现映射的结果必然扭曲业务对象，这类似于两个板块(数据表和业务对象)相撞，必然产生地震，地震的结果是两败俱伤， 软的一方吃亏，业务对象是代码，相当于数据表结构，属于软的一方，最后导致业务对象变成数据传输对象DTO, DTO满天飞，性能和维护问题随之而来。
领域建模解决了上述众多不协调问题，特别是ORM痛苦使用问题，关于ORM/Hibernate使用还是那句老话:如果你不掌握领域建模方法，那么就不要用Hibernate，对于这个层次的你:也许No ORM 更是一个简单之道: No ORM: The simplest solution
Spring分层矛盾问题
Spring是以挑战EJB面貌出现，其本身拥有的强大组件定制功能是优点，但是存在实战的一些问题，Spring作为业务层框架，不支持业务层Session 功能。
具体举例如下:当我们实现购物车之类业务功能时，需要将购物场合保存到Session中，由于业务层没有方便的Session支持，我们只得将购物车保存到 HttpSession，而HttpSession只有通过HttpRequest才能获得，再因为在Spring业务层容器中是无法访问到HttpRequest这个对象的，所以， 最后我们只能将“购物车保存到HttpSession”这个功能放在表现层中实现，而这个功能明显应该属于业务层功能，这就导致我们的Java项目层次混乱，维护性差。 违背了使用Spring和分层架构最初目的。
领域驱动设计DDD
现在回到我们讨论的重点上来，分层架构是我们使用Java的根本原因之一，域建模专家Eric Evans在他的“Domain Model Design”一书中开篇首先强调的是分层架构，整个DDD理论实际是告诉我们如何使用模型对象oo技术和分层架构来设计实现一个Java项目。
我们现在很多人知道Java项目基本有三层:表现层 业务层和持久层，当我们执著于讨论各层框架如何选择之时，实际上我们真正的项目开发工作还没有开始， 就是我们选定了某种框架的组合(如Struts+Spring+Hibernate或Struts+EJB或Struts+JdonFramework)，我们还没有意识到业务层工作还需要大量工作，DDD提供了在业务层中再划分新的层次思想，如领域层和服务层，甚至再细分为作业层、能力层、策略层等等。通过层次细化方式达到复杂软件的松耦合。DDD提供了如何细分层次的方式
当我们将精力花费在架构技术层面的讨论和研究上时，我们可能忘记以何种依据选择这些架构技术?选择标准是什么?领域驱动设计DDD 回答了这样的问题，DDD会告诉你如果一个框架不能协助你实现分层架构，那就抛弃它，同时，DDD也指出选择框架的考虑目的，使得你不会 人云亦云，陷入复杂的技术细节迷雾中，迷失了架构选择的根本方向。
现在也有些人误以为DDD是一种新的理论，其实DDD和设计模式一样，不是一种新的理论，而是实战经验的总结，它将前人 使用面向模型设计的方法经验提炼出来，供后来者学习，以便迅速找到驾驭我们软件项目的根本之道。
现在Evans DDD概念很火，因为它将著名的PoEAA进行了具化，实现了PoEAA可操作性，这也是MF大力推崇的原因。最近(8月8日)一位老外博客上用微软的.NET架构和Evans DDD比较的文章:比较了微软的三层服务应用架构[Microsoft TLSA]和Evans DDD的架构， 使用Microsoft .NET Pet Shop 4为例子，解释两个目标的区别，并且表明微软是如何在案例中更好地实现支持后者。这篇文章帮助哪些.NET平台上有域设计知识的人实现更好地提高。
另外一本关于.NET的DDD书籍也已经出版，这些都说明Evans DDD这把火已经烧到.NET领域，当然DDD在Java领域生根开花多年，Evans的DDD书籍就是以Java为例子的，笔者板桥里人也率先在2005年推出DDD框架JdonFramework 1.3版本，这些都说明，Java在整个软件业先进思想的实践上总是领先一步。
