什么是java架构？
作为一个概念，软件架构体现在技术和业务两个方面。
从技术的角度来看，软件体系结构是随着技术的创新而不断更新其内容的，软件体系结构是基于当前的技术和一些基本原理。
让我们来谈谈一些基本原则:
分层原则:分层是用来降低软件深度和复杂性的关键思想。就像社会有阶级一样，软件也有等级结构。
模块化原则:模块化是解决软件广度复杂性的必然手段，模块化的目的是使软件分工。
接口实现分离原则随着软件模块化的不断提高，用面向接口的编程代替面向实现的编程，可以降低日益复杂的软件中模块之间的耦合，从而使各个模块更容易改进。从这个原理出发，软件也从微观上进行了精心的规范。
有两个小但重要的原则:
隐藏细节的原理显然是把复杂的问题简单化，把丑陋的细节隐藏起来，可以让软件结构更加清晰。其实这个原则应用很广泛，java/c++语言中的封装原则和设计模式中的Facade模式都很好的体现了这个原则的精神。
依赖倒置原理随着软件结构的进一步发展，层与层之间、模块与模块之间的依赖逐渐加深，同时对层和模块的动态可插拔性的要求也不恰当地增加。依赖倒置原理可以看作是接口实现分离原理的深化。根据这一原则的精神，软件已经进入了工具时代。这个原则有点类似于众所周知的好莱坞定律:不要打电话给我们，我们会打电话给你。
这些原则为我们的软件架构的价值指数奠定了基础。但是软件架构毕竟是基于现在的技术。每一代技术都有一个架构模型。忘掉过去，我们来看看现在流行的技术，以及目前可以采用的架构。
因为面向对象是目前最流行的开发技术，设计模式的广泛使用使面向对象走向成熟，而数据库是目前最有效的存储结构，web界面是目前最流行的用户界面，所以目前最典型的三层架构就是基于上述技术，以数据库为存储层，以面向对象为业务层，以web为用户界面层。让我们从三层架构开始:
由于面向对象技术和数据库技术不匹配，我们在标准三层架构的基础上增加了数据持久层来管理O-R双向映射，但目前还没有理想的实现技术。Cmp和实体bean技术由于其复杂的实现和有限的功能前景而处于被淘汰的边缘。JDO和hibernate作为o-r映射的晚辈，尤其是hibernate，功能相当齐全。推荐作为持久层的首选。
在业务层，由于当前业务负载越来越大，变化频繁，我们必须有足够的敏捷技术来保证我们适应变化的能力。在标准的j2ee系统中，session bean负责业务处理，性能良好，但是ejb系统对业务架构模式改变太大，而且复杂昂贵，业务代码可移植性差。Spring作为轻量级架构，有bean配置和漂亮的IOC模式实现，对业务架构影响不大，推荐作为中间层业务框架。
在用户结构层，servlet/jsp/jstl/javaBean虽然可以实现MVC架构，但毕竟太粗糙了。Struts是MVC架构的完美实现，Taperstry也是MVC架构的优秀实现，基于事件的方式很吸引人，但是还不够成熟。我们仍然推荐struts作为用户界面层基础设施。
因为业务层是三层架构中最具决定性的，所以我们还是回到业务层来详细分析。在复杂业务中，我们往往需要以下一个或多个基础服务:事务一致性服务acid(工具:jta/jts)和并发锁定服务Concurrent & amp；& amp锁、池管理服务缓存、访问控制服务(工具:jaas)、流程控制服务工作流、动态实现服务IOC、序列化消息服务(工具:jms)、负载均衡服务blance等。如果不采用重量级的应用服务器(如weblogic、websphere、jboss等。)和重量级组件(EJB)，我们必须自己实现其中的一些服务。虽然我们在大多数情况下并不需要所有这些服务，但要实现它们并不容易。幸运的是，我们有很多开源的实现代码，但采用开源代码往往并不容易。
随着xml作为结构化信息的传输和存储越来越重要，一些xml文档操作工具(DOM、Digester、SAX等)的使用。)变得越来越重要，而且随着java绑定工具(jaxb、xmlbean等)的成熟。)中，采用xml schema来设计xml文档格式。那么使用java绑定生成java bean将成为主要的编程方式，这将进一步把数据中心转移到xml上，使以xquery为查询语言的xml数据库越来越倾向于中小型数据。最近有一种趋势，微软、ibm等。已经开发了大量的中间软件，比如微软office的infopath，可以直接从xml schema生成输入页面等非常实用的功能。web服务的广泛应用将对软件体系结构产生非常重大的影响。至于面向服务架构(SOA)的前景以及三层架构何时走入历史，现在还很难下定论。
aop的发展也会对软件架构产生深远的影响，但是在面向对象架构中，无论是aspectJ、jboss-aop还是aspectWerks和南宁都有自己严重的问题:可维护性差，所以会很难走远。也许这是一个好主意，它将在web服务中发挥重要作用。
RDF和OWL作为w3c语义模型的符号语言，很难想象它们能对当前的业务架构产生多大的影响。但是如果它真的像它声称的那样广泛地改变了信息的结构。那么就会对软件架构产生深远的影响。
关于建筑设计的一些建议:
尝试建立一个完整的持久对象层。可以获得高收益。
尝试对每个功能进行分层和分块，每个模块都依赖于其他模块的假定外观。
实现IOC模式不能靠静态数据，要靠数据特征接口，静态数据只是实现数据特征接口的方式之一。
Xml在架构设计中是一种支持而不是依赖，但是它可以提供单一版本的xml。
从业务的角度来看，软件架构应该是深度反映业务内部规则的业务架构，但由于业务变化频繁，很难保持软件架构不变。但是，频繁的业务变更不应该成为软件架构大规模频繁变更的原因，软件架构应该以变更为基础。
一个企业有它在一段时间内稳定存在的理由(暂且不谈)。业务中有很多用例，每个用例都有固定的规则。每个规则都有一些可以判断的条目，每个条目都是从某个维度可以衡量的。我们的架构必须首先确保对每个项目和每个测量方法的完美适应。很多失败的架构都是因为很多项目的度量方法发生了微小的变化。
每个用例都有规则。当我们分析业务用例时，我们经常假设一些规则是先验的和持久的，但是后来的业务变化经常证明这种观点是错误的。然而，往往我们的架构已经为此付出了不可挽回的代价。大量事实证明，规则的变更往往是用例变更的根本原因。所以我们的架构要尽可能的适应规则的变化，尽可能的建立规则模板。
每个用例都与不同的角色相关。每一个用例都必然是由角色的变化引起的(注:不是替换，而是增强或减弱)，所以关注角色的各种可能情况对架构的设计有着重要的意义。在我们当前的三层架构中，角色与接口概念完全对应。
在一个系统中，许多用例是相互关联的。考虑到每个用例可能有不同的特例，在架构设计上尽量采用依赖倒置的原则。如果架构允许，可以采用消息通信模式(JMS)。这可以降低耦合度。
现在来说说业务稳定的原因对业务的影响。存在即合理，在这里当然是正确的。业务是为人而存在的，所以问一个业务存在的原因，就意味着问不同的角色为什么需要这个业务，为什么喜欢或者不喜欢当前的业务用例。所有这些角色都应在系统中保留。待续
在架构设计中有几个原则需要考虑:
尽可能细分的用例。
尽可能抽象的用例。
尽可能的独立
项目测量独立性原则
追求简单
此处未提供示例，但将在未来的更新中提供。
商业和模式的关系
业务中的一些用例之间的关系通常与一些常规模式非常相似。但随着时间的演变，逐渐与之前的模式发生了背离。这是正常现象。但这需要非常高的系统架构，需要系统架构适应一些模式的更替。在这里，我们尽早注意到用例之间的角色变化，为架构更新做准备。