摘录原文链接：天极网
常见的软件体系架构
l 三层体系架构
在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层(又或成为领域层)、表示层，如图所示：
图2 三层体系架构
数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问。简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。
业务逻辑层(BusinessRules)：是整个系统的核心，它与这个系统的业务(领域)有关。以STS系统为例，业务逻辑层的相关设计，均和销售跟踪的逻辑相关。在结构上它封装了数据访问层的相关操作。该层主要由实现具体业务逻辑的类组成。
表示层(WebUI)：是系统的UI部分，负责使用者与整个系统的交互。在这一层中，理想的状态是不应包括系统的业务逻辑。表示层中的逻辑代码，仅与界面元素有关。在当前项目中，是利用ASP.NET来设计的，因此包含了许多Web控件和相关逻辑。
l 五层体系架构
SaaS软件体系架构也可以分为五层，从上而下分别为：用户界面层(表现层)、业务逻辑层、通用层、应用框架层、远程访问(WebService)层、数据访问层，如图所示：
图3 基于微软的.NET架构设计
用户界面层(UI)
用户界面层是用户直接操作的界面。该层由界面外观、表单控件、框架及其它部分构成。用户界面层负责使用者与整个系统的交互。在这一层中，理想的 状态是不应包括系统的业务逻辑。表示层中的逻辑代码，仅与界面元素有关。在当前项目中，是利用ASP.NET来设计的，因此包含了许多Web控件和相关逻 辑。
² 界面外观包括skip(皮肤)、Images(图片)、css(样式表)
² 表单控件主要包括常用表单、用户自定义控件。
² 框架主要包括Master Page、Frame Page。
² 其它主要包括JavaScript文件、Dll文件、Report报表、Schema建数据库、Model开发模板。
业务逻辑层(BusinessRules)
是整个系统的核心，它与这个系统的业务(领域)有关。以STS系统为例，业务逻辑层的相关设计，均和销售跟踪的逻辑相关。在结构上它封装了数据访问层的相关操作。该层主要由实现具体业务逻辑的类组成。
² BLFactory 业务逻辑工厂
² IBL 业务逻辑接口
² BusinessRules 业务逻辑实现
通用层
通用层贯穿整个项目的表示层和业务逻辑层。主要存放该项目中较为通用的常量定义和通用服务(Service)，这里指的Service是当前项目业务逻辑上通用的方法，我们把它们写在对应的静态类中。以服务的形式提供。
CommonLayer：存放通用的常量及方法。
数据访问层
该层结构是最复杂的，主要由以下层组成：数据访问工厂层(DALFactory)，数据访问接口层(IDAL)，自定义查询层(PersistenceFacade)，临时层(DataAccessLayer)，数据持久层(PersistenceLayer)。
下面由下向上介绍：
² PersistenceLayer层，这是框架设计的最底层(除应用框架层外)。它主要负责用ORM思想将物理数据库对象化。简单来说就是将数据库表映射 为实体类，将相应的字段映射为类的属性。这样一来物理数据库对于开发者是完全透明的，应用ORM的思想我们彻底摆脱了物理数据库。并且独立于数据库具体实 现。
² 具体实现我们应用著名的开源项目Castle下的轻量级数据访问组件ActiveRecorder实现。
² PersistenceFacade层和IDAL，这里定义了项目中用到的所有查询方法。与PersistenceLayer层定义的数据实体相对应。在 这些字定义的查询类中可以应用ActiverRecorder提供的三种查询方法(ActiverRecorderBase提供的简单接口，简单查询 SimpleQuery，自定义查询CustomerQuery)的任意组合。并且这里的每一个类都要实现IDAL接口层定义的相关接口。
² DALFactory层，做为数据访问的工厂，通过.Net的反射机制调用IDAL和PersistenceFacade组成的数据访问组件中的相关操作。
² DataAccessLayer临时层。首先声明这层是完全没有必要的。因为我们在项目中是可以不写任何Sql语句的。所有的Sql都用Hql代替。设计 这层的目的是为了允许项目组中的人员的技术过渡。此层可以通过Sql操作数据库(不推荐)。架构稳定后本层将不再提供。
应用框架层(Framework)
本层的目的是技术沉淀。将项目之间通用的东西移入应用框架层达到代码重用的目的。本层以后可以黑盒化。可以包括通用的组件。
² Framework：积累一些可以抽象出来的方法及控件
² MSMQMessag：消息处理队列的实现
² Pager：通用翻页类
² Report：通用报表类
² Controls：控件处理类
² DataFormat：数据格式转换类
² WebUI：页面处理类
² Validate：数据校验
² Object：对象之间的转换及访问
5 分层式体系结构的好处
1、开发人员可以只关注整个结构中的其中某一层;
2、可以很容易的用新的实现来换原有层次的实现;
3、可以降低层与层之间的依赖;
4、有利于标准化;
5、利于各层逻辑的复用。
概括来说，分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定义。
一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。例如UI人员只需考虑用户界面的体验与操作，领域的设计人员可以仅关注业务逻辑的设计，而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认，开发进度就可以迅速的提高。
松散耦合的好处是显而易见的。如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相互依赖，谁都是不可替换的。一旦发生改变，则牵 一发而动全身，对项目的影响极为严重。降低层与层间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明显。每个功能模块一旦定义好统一的接 口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。
进行好的分层式结构设计，标准也是必不可少的。只有在一定程度的标准化基础上，这个系统才是可扩展的，可替换的。而层与层之间的通信也必然保证了接口的标准化。
“金无足赤，人无完人”，分层式结构也不可避免具有一些缺陷：
1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
6 软件架构视图
Philippe Kruchten在其著作《Rational统一过程引论》中写道：
一个架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体。
也就是说，架构要涵盖的内容和决策太多了，超过了人脑“一蹴而就”的能力范围，因此采用“分而治之”的办法从不同视角分别设计;同时，也为软件架构的理解、交流和归档提供了方便。
图4 Philippe Kruchten提出的4+1视图方法
该方法的不同架构视图承载不同的架构设计决策，支持不同的目标和用途：
l 逻辑视图：当采用面向对象的设计方法时，逻辑视图即对象模型。
l 开发视图：描述软件在开发环境下的静态组织。
l 处理视图：描述系统的并发和同步方面的设计。
l 物理视图：描述软件如何映射到硬件，反映系统在分布方面的设计。
图5 运用4+1视图方法针对不同需求进行架构设计
逻辑视图。逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”;它们可能是逻辑层、功能模块等。
开发视图。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
处理视图。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包 在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。
物理视图。物理视图关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠 性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题;物理视图是综合考虑软 件系统和整个IT系统相互影响的架构视图。