目录
1 企业应用架构 1
1.1 企业应用架构 1
2 表现层 1
2.1 表现层 1
3 业务层 2
3.1 业务层 2
3.2 业务分层 3
3.3 业务模块化 3
4 数据层 3
4.1 数据层 3
4.2 数据缓存 3
5 架构思想 6
1 企业应用架构
1.1 企业应用架构
企业应用架构比较经典的是三层架构，它包括表现层，业务层，数据访问层。
表现层负责见面呈现及UI逻辑处理。
业务层负责处理业务逻辑，并与上层表现层和下层数据访问层交互。
数据访问层负责数据持久化，数据的读取和写入，并与上层业务层和数据库交互。
传统的企业开发常常使用MVC（视图-逻辑-模型）开发模式来开发企业应用，如SSH架构开发，但随着软件应用规模的壮大，传统的开发模式已经很难满足企业应用需求。在传统的MVC架构基础上，分别将表现层，业务层，数据层剥离出来，对各层进行开发，而各层之间通过通信来进行交互，这种通信交互就是一种服务化的过程。如业务层可以向表现层提供业务逻辑处理服务，数据层可以向业务层提供数据访问服务。这种分层的剥离和服务化的开发使得企业应用更加能满足业务需求开发。
2 表现层
2.1 表现层
在表现层中随着软件应用规模的壮大，单一的UI界面无法满足企业应用的需求，应用需要表现层支持多种界面，在架构分层剥离和服务化的开发架构中只需扩展表现层来调用业务层的服务，就可使得表现层支持多种界面呈现。使得表现层的开发更加灵活，更加容易扩展。
3 业务层
3.1 业务层
在业务层中可以通过服务接口向表现层提供服务，而表现层通过服务接口调用服务实现。通常可通过Rest和Web Service实现web服务。
3.2 业务分层
在一些架构中为了实现多服务协议和便于对业务服务的管理，通常可将业务层分离为服务层和业务层。服务层负责向外提供服务，业务层负责处理业务逻辑和管理业务的领域模型DM（Domain Model）。业务层和服务处可以通过RPS（远程调用）进行通信。如RMI，Hessian/Burlap等。
3.3 业务模块化
在一些架构中由于业务需求不断频繁的变更和增加，需要架构支持易扩展，易升级，开发高效等需求，通常可以将业务进行特性分解，根据业务的特性对业务层模块化，也可以说是将业务层转换为组件式开发。
将业务层模块化要注意模块与业务之间的关系，同时也要注意模块与模块之间的关系。
模块与业务之间的关系，模块依赖于业务，可以根据业务的特性分解来模块化业务层。
模块与模块之间的关系，模块与模块之间会存在交互，这种交互会使得模块与模块之间会存在依赖关系。这些依赖关系要尽量避免，特别是循环依赖（多模块之间存在循环依赖，A模块依赖B模块，B模块依赖C模块，C模块依赖A模块。），网状依赖（多模块之间存在网状依赖关系），反转依赖（下层模块依赖上层模块）。
随着模块化的增加，模块之间的依赖关系复杂，为了便于理清模块间的关系和管理，可以将模块归类，即根据业务特性或者模块依赖特性将模块归类，同类的模块归类到一个模块域中。通过模块域可以更好的管理模块的依赖。
4 数据层
4.1 数据层
在数据库服务层中，企业应用需要操作的数据很可能来自不同的数据库，可以通过数据层实现统一数据访问，通常通过ORM（Object/Relation Mapping）对象关系映射来实现数据表和对象的映射关系，通过程序操作对象来操作数据。如Hibernate，iBATIS。数据层为业务逻辑层提供了统一的数据接口服务。
4.2 数据缓存
在数据层中需要提供访问性能和减小数据库访问压力时，常常可以通过在数据层中构建一个数据库缓存层来实现数据缓存，这样可以提供数据服务性能，同时也可以缓解数据库的访问压力。如Redis Memcache缓存数据库。
5 架构思想
架构的构建过程就是将系统水平切分与垂直切分的过程。切分的过程赖于业务。
----------------------------------------------
未完待续