一、架构之传统三层架构

传统三层架构是一种软件架构，是一种典型的、基于贫血模型的、面向过程的JavaWeb分层方式。该架构分为以下三个层次：

1. 数据访问层（DAL - Data Access Layer）即对包括数据库在内的数据源进行操作的部分。
2. 业务逻辑层（BLL - Business Logic Layer）即对业务数据进行逻辑处理的部分。
3. 表现层（UI - User Interface）即与用户交互的部分。

分层的目的是为了解耦和明确责任。开发人员可以只关心自己所负责的那一层，因为他只需要知道上一层提供了哪些接口，从而利用这些接口进行编程。而上一层的开发人员在不改变接口的情况下，可以任意地替换具体的实现，从而实现松耦合。

相比更传统的架构，三层架构有着明显的优势，但也有不可忽视的缺点。初期的JavaWeb在JSP内同时进行数据库读写、业务逻辑处理和页面渲染，简单而暴力。而今的架构，在JSP之上增加了一个处理业务逻辑的中间层和一个封装了数据库操作的数据访问层，毫无疑问造成了代码量的大幅度上升和效率的下降。

本项目中，Mybatis承担数据访问的责任；SpringMVC包揽了页面渲染和请求调度；Spring的IoC和AOP组成了整个项目的支架；Spring的事务控制为业务逻辑层的一致性提供了强有力的保障。

不同的语言、不同的框架对三层架构有不同的演绎，但殊途同归，业务数据的流向是一致的。下面以一个点菜的例子来示范这一点：

二、架构之领域模型架构

领域模型的概念源于2004年出版的经典著作《Domain-Driven Design –Tackling Complexity in the Heart of Software》（《领域驱动设计：软件核心复杂性应对之道》，简称DDD）。所谓领域，即软件所关注的主题区域：

每个软件程序的目的都是为了执行某项活动，或是满足用户的某种需求。用户会把软件程序应用于某个主题区域，这个区域就是软件的领域。一些领域涉及物质世界，例如机票预订程序的领域中包括飞机乘客在内。有些领域则是无形的，例如会计程序的金融领域。——摘自《领域驱动设计》第一章

该著作提出，设计软件分为两个步骤：

1. 由领域专家、开发人员、设计人员就某一领域进行交流，从中发现领域概念，并根据需要，划定边界，将边界内的概念抽象为领域模型。
2. 由领域模型驱动软件设计，用代码来实现该模型。

基于此，DDDSample官网提出了另一种三层架构：

如图，该架构分为界面（Interfaces）、应用（Application）和领域（Domain）三层，以及一个基础设施（Infrastructure），是一种基于充血模型的、面向对象的分层方式。其各层职责如下：

2.1、界面层（Interface）

负责所有与外部系统的交互，包括WebService、RMI或REST等。包括外观（Facade）、装配（Assembler）和数据传输对象（DTO）三类组件：

1. DTO组件：因为领域对象不适合暴露给用户，因此需要在返回给用户之前，重新封装为DTO，只暴露我们希望暴露的内容。同时，DTO还有减少请求的次数、简化传输对象、避免代码重复等作用。
2.  Assembler组件：正如其字面上的含义，Assembler是一个装配工人，负责DTO与领域对象的转换。
3. Facade组件：Facade是外观模式的践行者，作用与传统三层架构的Controller类似，负责将一个或多个service方法组合起来，然后封装为一个接口提供为外部系统。换句话说，他负责将外部请求委派给一个或多个service进行处理。他本身不处理任何业务逻辑。

2.2、应用层（Application）

应用层的主要组件就是Service，其粒度与传统三层架构的service一致。差别在于，传统三层架构的service层负责业务逻辑的处理，而领域模式三层架构的service只负责将业务委派给领域对象进行处理。

2.3、领域层（Domain）

这一层是整个软件的核心，几乎包括了所有的业务逻辑。他包括了Entity（实体）、Value Object（值对象）、Domain Event（领域事件）和Repository（仓储）等领域组件。下面以时下很火的共享自行车为例来简单解释这几个组件：

1. Entity/Value Object：实体是一个在业务领域有着唯一标识的对象。实体有属性和状态，有业务行为，其业务行为会影响他的属性和状态。而值对象呢，用于描述没有唯一标识的对象。
2. Domain Event：简单的说，实体触发事件，实体绑定事件。用户的租赁行为会触发租赁事件；而自行车绑定了租赁事件，当事件发生时，自行车的使用状态发生改变。
3. Repository：仓储类似于传统三层架构的DAO接口，但只是接口，不包括实现。

举个栗子，当我们希望对每一辆共享自行车进行管理时，他应该被设计为实体，有唯一编号作为标识，有颜色、重量、价格、品牌等属性，有位置状态、使用状态，有租赁行为。当其被租赁时，其位置状态和使用状态可能发生改变。

同样是共享自行车，如果我们的系统只为了统计各地区各品牌自行车的使用情况，即我们只关心他是什么，而不关心他是谁，那么他应该被设计为值对象。

2.4、基础设施（Infrastructure）

作为基础设施，Infrastructure负责给三层架构提供支持。所有与具体平台、框架相关的实现都会在这一层实现，以免影响三层架构职责的纯粹性、以及污染领域模型。对象持久化的具体实现也放在基础设施里。

三、传统三层架构 VS 领域模型架构

从领域模型架构各层的职责可以看出，他和传统三层架构最大的差别在于，领域模型架构的业务逻辑包含在领域模型里，而传统三层架构的业务逻辑在Service层。为了实现这一点，领域模型还引入了在Javascript和ActionScript中常见的事件机制；而传统三层架构中，领域模型的属性和行为严格分离，变成了POJO和Service。

个人认为，两种架构的出发点是相同的，一样是先挖掘领域概念，然后建模，再根据模型进行设计。差别在于，当业务逻辑的复杂程度在单个开发人员或单个团队的把控能力范围之内时，采用面向过程的传统三层架构可以很快地完成建模工作，并开始业务逻辑的设计；而当业务逻辑复杂到一定程度时，则有必要花更多的时间用在建模上，去抽取模型的行为，去设计和关联模型事件，以期在后续迭代中，开发人员只需面对一个个可以清晰地理解的领域对象，而不是一坨动辄上千行的某业务行为的逻辑代码。

综上考虑，大部分web系统可以采用传统三层架构。

四、模型的形态

不同的架构、不同的层、不同的应用场景中有着不一样的建模需求，因此表述相同概念的模型可能会有不同的“形态”，例如：

1. 充血模型 - 领域模型架构中包含了领域逻辑和领域属性的领域模型。
2. 失血模型 - 传统三层架构中只有get/set方法，没有业务逻辑的POJO对象。
3. 贫血模型 - 类似充血模型，但是不包括持久化相关逻辑。
4. PO - Persistant Object，持久化对象，即DAO从JDBC取出来的对象。传统三层架构中，PO即POJO组件中的对象，存在于DAO和Service之间。
5. DO - Domain Object，领域对象。领域模型架构中，PO从数据库取出来后，有一个“重建”的概念，即根据数据还原实体，这个被还原的实体就是DO，存在于DAO和Service之间。
6. DTO - Data Transfer Object，数据传输对象。上面在领域模型架构的界面层提过。对传统三层架构来说，该对象存在于Service和Controller之间。PO到DTO的转换可以在service实现，也可以在controller实现。本教程在Service进行转换。
7. VO - View Object，视图对象。Controller在返回DTO给视图时，可能还需要包括状态信息—例如操作成功/失败的状态吗、提示文本等—这时就需要在DTO外面再包一层，即View Object。该对象存在于Controller和Web之间，由Controller进行装配。

四、MVC模式

跟架构密切相关的另一个词汇是MVC模型，即Model-View-Controller模式。MVC模式是一种设计软件的模式，不是一种架构。在传统三层架构中，MVC的理念被应用在表现层：View提交请求数据给Controller，Controller返回数据用于渲染View，两者之间以Model(VO - ViewModel)的形式进行通信。如下图：

参考文章地址：https://my.oschina.net/mzdbxqh/blog/865046