系统架构分析

传统的三层架构

简介

各层之间采用接口相互访问，并通过对象模型的实体类(Model)作为数据传递的载体，不同的对象模型的实体类一般对应于数据库的不同表，实体类的属性与数据库表的字段名一致。

职责划分

层	描述
User Interface layer(表示层, UI)	接受对用户的请求并返回数据，将结果呈现给用户。
Business Logic Layer(业务逻辑层, BLL)	主要负责接受表现层的请求，进行各种业务逻辑运算，然后通过数据访问层完成数据的操作。
Data Access Layer(数据访问层, DAL)	主要负责数据的查询、持久化等操作，关注数据一致性、准确性，不关注业务逻辑

从上面的职责划分可以看出，此架构模型符合“高内聚，低耦合”思想；其特点是以数据库为起点进行系统分析和设计。

包结构

典型的目录结构划分：

• com.xxx.project
  • service(biz、manager) ：各种业务逻辑放在此包中实现
  • view：负责视图层
  • dao：负责db的数据访问

分布式架构

DDD分层架构

简介

DDD的核心是领域层。每层只能与其下方的层产生依赖。
注：图中在「四层架构」的基础上演进行成了「依赖倒置的四层架构」，各层通过仓储接口来方位基础层。

职责划分

User Interface(用户接口层)

职责：
负责向用户显示信息、解释用户命令。这里的用户可以是真正的用户、自动化测试程序、批处理脚本等。
主要包括：
外观接口(facade)：用于封装应用服务，完成不同前端的数据适配。
转换器(assembler)：用于将领域对象转换成VO对象。
示例：
PC端要显示订单的完整信息，但是App端仅需要显示少量核心数据；对内应用的数据返回相对完整，但是对外提供Api是仅返回指定的几个字段。这些场景中接口的核心逻辑都一样，只是因为渠道的不同，需要对不同渠道做不同适配，这些都应该在用户接口层完成。

Application Layer(应用层)

主要负责：
协调领域层多个领域服务，面向业务流程完成服务的组合与编排。应用层的服务被用户接口层Facade服务封装，完成接口和数据适配，通过Api网关对前端应用提供服务。
主要包括：
应用服务、领域事件订阅与发布、安全认证、权限校验、事务控制、对其他微服务调用、等等。
事件(event)：用于封装领域事件的订阅预发布。
应用服务(service)：负责对领域服务、其他应用服务的封装、编排、组合。
主要特点：
这一层都很薄，主要是服务的组合与编排。
特别注意：
不要将领域层的逻辑放在应用层中实现，否则很容易导致应用层、领域层的边界混乱，最终导致DDD的四层架构变成三层架构。

Domain Layer(领域层)

主要职能：
实现领域对象或者聚合自身的原子业务逻辑，关注领域模型的能力，不太关注外部用户操作或者流程方面的控制。
主要包括：
领域服务、值对象、实体、聚合、聚合根等。
实体(entity)：用于存放聚合根、实体、值对象等。
事件(event)：用于封装领域事件处理的核心逻辑。
领域服务(service)：用于存放领域服务、工厂类等代码。
仓储(repository)：用于存放仓储服务的代码，隔离领域逻辑和数据存储。
领域服务：
组合、协调聚合内的多个实体或值对象，实现复杂的业务逻辑。

Infrastructure Layer(基础设施层)

主要职能：
为其他各层提供通用的技术和技术服务。
主要包括：
封装消息中间件、网关、缓存、文件服务、数据库等。
主要作用
封装基础资源的服务，实现应用层、领域层、基础层解耦，降低对外部资源依赖。例如：如果没有此层，当消息中间件、缓存变化时，将会大面积修改业务逻辑。