越来越多人开始运用Java，但是他们大多数人没有做好满意的思想准备(没有接受OO思想体系相关操练)，致使不能很好驾御Java项目，甚至导致开发后的Java体系功用缓慢甚至常常当机。许多人觉得这是Java凌乱导致，其实根柢原因在于:我们原先把握的关于软件常识(OO方面)不是太匮乏便是不恰当，存在认识上和方法上的误区。
软件的生命性
软件是有生命的，这或许是老调重弹了，但是因为它事关分层架构的原由，重复侧重都不过火。
一个有生命的软件首要有必要有一个活络可扩展的基础架构（tianpintangshui），其次才是无缺的功用。
现在许多人对软件的思想仍是焦点落在后者:无缺的功用，觉得一个软件功用越无缺越好，其实要害仍是架构的活络性，便是前者，基础架构好，功用增加只是时间和作业量问题，但是假定架构欠好，功用再无缺，也不或许包括未来悉数功用，软件是有生命的，在未来生长时，更多功用需求参加，但是因为基础架构不活络不能便当参加，死路一条。
正因为普通人对软件存在短视误区，对功用寻求高于基础架构，许多吃了亏的老程序员就此脱离软件作业，带走贵重的失利阅历，新的盲目的年青程序员仍是运用老的思想往前冲。其实许多国外免费开源结构如ofbiz compiere和slide也存在这方面圈套，形似十分符合胃口，其实类似国内那些几百元的盗版软件，扩展性以及持续发展性严重不足。
那么选择现在一些盛行的结构如Hibernate、Spring/Jdonframework是否就标明基础架构打好了呢?其实还不尽然，要害仍是取决于你怎样运用这些结构来树立你的业务体系。
存储进程和凌乱SQL语句的圈套
首要谈谈存储进程运用的误区，运用存储进程架构的人认为可以处理功用问题，其实它正是导致功用问题的元凶巨恶之一，打个比如:假定一个人频临逝世，打一针可以让其延伸半年，但是打了这针，其他悉数医疗方案就悉数失效，请问你会运用这种短视方案吗?
为什么这样说呢?假定存储进程都封装了业务进程，那么作业负载都会集在数据库端，要中心J2EE运用服务器干什么?要中心服务器的分布式核算和集群才调做什么?只能回到从前会集式数据库主机年代。现在软件都是面向互联网的，不象从前那样束缚在一个小局域网，多用户并发拜访量都是无法确认和衡量，依托一台数据库主机显然是不可以接受这样恶劣的用户拜访环境的。(当然搞数据库集群也只是五十步和百步的差异)。
从分层角度来看，现在三层架构:体现层、业务层和耐久层，三个层次应该切开明显，责任分明:耐久层责任耐久化保存业务模型方针，业务层对耐久层的调用只是协助我们激活早年托付其保管的方针，所以，不能因为耐久层是保管者，我们就以其为中心环绕其编程，除了要求其偿还模型方针外，还要求其做其做凌乱的业务组合。打个比如:你在火车站将生果和盘子两个方针托付保管处保管，过了两天来取时，你还要求保管处将生果去皮切成块，放在盘子里，做成生果盘给你，合理吗?
上面是谈过火依托耐久层的一个现象，还有一个正好相反现象，耐久层宣布出来，开始抢占业务层，腐蚀业务层，整个业务层处处看见的是数据表的影子(包括数据表的字段)，而不是业务方针。这样程序员应该多看看OO经典PoEAA。PoEAA 认为除了耐久层，不应该在其他地方看到数据表或表字段名。
当然适量运用存储进程，运用数据库利益也是答应的。依照Evans DDD理论，可以将SQL语句和存储进程作为规矩Specification一部分。
Hibernate等ORM问题
现在运用Hibernate人也不少，但是他们发现Hibernate功用缓慢，所以寻求处理方案，其实并不是 Hibernate功用缓慢，而是我们运用方法发作错误:
Hibernate是一个依据方针模型耐久化的技术，因此，要害是我们需求规划出高质量的方针模型，遵循DDD领域建模原则，削减降低相关，经过火层等有用方法处理相关。假定采纳环绕数据表进行规划编程，加上表之间联络凌乱(没有科学方法处理、侦查或削减这些联络)，必定导致 体系作业缓慢，其实相同问题也适用于开始对EJB的实体Bean的CMP抱怨上，实体Bean是Domain Model耐久化，假定不首要规划Domain Model，而是规划数据表，和耐久化东西规划方针各走各路，能不出问题吗?关于这个问题N多年就在Jdon争论过。
这儿相同延伸出其他一个问题:数据库规划问题，数据库是否需求在项目开始规划?
假定我们进行数据库规划，那么就产生了一系列问题:当我们运用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的根柢原因之一（cooLsanguo），域建模专家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为比如，说明两个方针的差异，而且标明微软是怎样在事例中更好地完毕支撑后者。
原文：https://www.cnblogs.com/monkey7788/p/12088424.html