软件架构的概述（待补充）

1.软件架构的基本介绍

架构架构师：与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。

软件架构

一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

2.软件结构设计的目的

可重用：为大规模开发提供基础和规范，并提供可重用的资产，软件系统的大规模开发，必须要有一定的基础和遵循一定的规范，这既是软件工程本身的要求，也是客户的要求。架构设计的过程中可以将一些公共部分抽象提取出来，形成公共类和公共接口，其他功能模块所需相关功能即可调用，以达到重用的目的。
缩短周期：一定程度上缩短项目的周期，利用软件架构提供的框架或重用组件，缩短项目开发的周期。
降低开发和维护的成本：大量的重用和抽象，可以提取出一些开发人员不用关心的公共部分，这样便可以使开发人员仅仅关注于业务逻辑的实现，从而减少了很多工作量，提高了开发效率。
提高产品的质量：好的软件架构设计是产品质量的保证，特别是对于客户常常提出的非功能性需求的满足。

3.软件架构的基本设计原则

满足功能性需求和非功能需求：这是一个软件系统最基本的要求，也是架构设计时应该遵循的最基本的原则。
实用性原则：就像每一个软件系统交付给用户使用时必须实用，能解决用户的问题一样，架构设计也必须实用，否则就会“高来高去”或“过度设计”。
接口复用：公共部分可设计成接口，减少冗余，最大程度的提高开发人员的工作效率。
低耦合：耦合是描述模块之间的依赖程度，如果一个模块的修改，都有另一个模块会受到影响，则两模块之间是相互依赖耦合的。（依赖具有传递性，耦合的两个模块可能间接依赖），低耦合是我们的设计目的，但不是不可以存在耦合不存依赖，依赖是必须的，因为模块之间是必须要通信交互。设计依赖应该依赖于不变或者不易变的接口，无需了解模块的具体实现，即为面向对象的封装性。
高内聚：高内聚是指某个特定模块包括程序、类型都应完成一系列相关功能，描述了不同程序和类型中方法，方法中不同操作描述的逻辑之间的距离相近。高内聚意味可维护性，可重塑性，因为模块对外部的依赖少（功能的完备性）。如果两个模块之间的修改，互不影响各个模块的业务，这说明模块之间是高内聚的。模块的内聚和其担当的职责成反比，即模块的职责越多，模块的内聚性越低，这也是模块的单一原则（SRP），SRP提倡每个类型都最好只承担单一的职责，只有单一的改变因素。

4.软件架构设计的基本视图

由于软件系统的不同的角色会站在不同的角度上提出的问题，我们就得从不同的视角来看待软件架构设计这项工作：

逻辑架构视角：从系统用户的角度考虑问题，设计出来的软件架构能够满足业务逻辑的需求，能够处理现在越来越复杂的业务逻辑需求。
开发架构视角：从系统开发人员的角度来考虑问题，设计的架构要易于理解，易于开发，易于单元测试，最好做到让开发人员可以用最少的代码行数完成功能的开发。
运行架构视角：从系统运行时的质量需求考虑问题，特别关注于系统的非功能需求，客户常常都会要求我们系统的功能画面的最长响应时间不超过4秒，能满足2000个用户同时在线使用，基于角色的系统资源的安全控制等。
物理架构视角：关注系统安装和部署在什么样的环境上，例如现在最流行的企业应用服务解决方案IBM Http Server ＋ WebSphere Application Server ＋ DB2，WebLogic + Oracle等。
数据架构视角：如今我们开发的各类系统，如管理信息系统（Management Information System，MIS）、ERP（企业资源计划），SAP，基本上都是对各类数据的操作，把一堆不太好懂的数据展现成用户容易看懂的数据，自动处理各类数据的运算等，所以数据的持久化是十分重要的一件事情。

架构（Architecture）不是框架(Framework)，也不是简单的将几种框架或技术的组合，框架本身也是有架构的。框架一般是针对于某一方面或领域的重用性和可扩展性非常好的半成品，我们可以用一句较为经典的话来总结：框架是软件，架构不是软件，框架是一种特殊的软件。我们在工作中通过将许多方面的可重用的工具类，公共类，基础类等抽象出来，即可形成一些可重用的框架。
架构设计绝不是新技术展示平台，合适的技术才是对于项目有利的技术，必须考虑到开发人员的能力和维护人员的能力。作为一名架构设计师应该更多的考虑如何平衡业务需求，织织运作（主要指团队中的协作）和技术三者的关系，而不仅仅是去关注那些技术细节。

5.软件架构设计的通用技巧

• 分层（Layer）规则：
  这里的层是指逻辑上的层次（Layer），并非指物理上的层次（Tier）。目前的绝大多数的企业级应用系统中都分为三层，即表现层，领域层和数据层。在对各层次进行划分时，主要可以从以下几个方面来考虑：
  A、每一层是一个相对独立的部分，可以作为一个整体，无需对其它层了解；
  B、将层次间的依赖性降到最低，即降低耦合；
  C、可以从某种程度上替换掉某一层，而对其它层不会产生过多的影响；
  D，层次并不能封闭所有的东西，假如用户界面上增加了一个栏位，那么领域层就要增加一个数据域，数据层就要增加一个相应的字段。同时，过多的分层可能会对性能造成一定的影响。

• 包（package）之间不要产生循环依赖：通常包的划分会先按不同的逻辑层来划分，在层的包下面再按功能来划分。避免包间的循环依赖是一个比较通用的规则，这样的规则一定有其存在的价值和道理，之所以这样主要是出于以下原因：
  A、循环依赖会使分层失去意义；
  B、循环依赖会带来许多潜在的风险，如可能会产生嵌套事务（nested transaction，JavaEE标准中并不支持这种事务）的现象

• 设计模式的应用：在很多人的观念里，提供设计模式就等同于GOF的设计模式，其实设计模式是个广泛的概念，比如需求模式、领域模式、反模式等都属于设计模式。模式其实是一门工具，是人们对于过去解决某一类问题的经验总结，所以我们可以在设计活动中应用各种设计模式，但是在应用这些模式之前一定要先分析清楚问题，否则就可能出现“牛头不对马嘴”的现象。