一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第17天，点击查看活动详情。
架构分层
架构分层是将软件模块按水平切分多个层级，即一个项目由多个模块组成，一个模块划分多个层级，每个层级处理不用的事情，有自己独立的职责。
三层架构
以前刚接触软件开发时，第一次接触的分层是三层/四层架构。
- 表现层 UI ，就是视图层，展现给用户的界面
- 业务逻辑层 BLL，领域层，主要负责业务逻辑的处理，service层
- 数据访问层 DAL，对数据进行 增删改查操作，直接操作数据库的
MVC
MVC： model 模型， view视图， controller控制器 。
- 用户发出请求时，由相应的 controller 接收用户请求，然后再将结果响应给用户
- model 主要是承载数据，对用户提交的请求进行计算的模块。model 其实由 两类的功能，一是承载数据，二是进行详细的业务逻辑处理
- 视图是为用户提供使用界面，与用户直接进行交互的
旧架构的设计中 UI 层其实就是将 MVC 架构的 分化成 控制器，视图，实体三个部分。所以往往设计的架构中在 mvc 的基础上在，业务逻辑层再进行层级划分，比如Service 层， DAO 层，对外接口层，持久层。
DDD分层
DDD 是一种新的架构设计的方法论，主要是围绕业务概念构建领域模型，分离技术实现复杂领域的业务。层级划分如下：
- 基础层，部分数据，公共基础组件，缓存，网关，消息中间件等可以被所有层调用的层级
- 领域层，负责核心业务逻辑处理，领域层通过接口方式调用外部依赖
- 应用层，聚合多个领域层的能力，只做功能的组合，转发，不负责具体的业务逻辑
- 用户接口层，该层包含与其他系统的交互的所有内容，接口层处理传入数据的解释、校验、编解码、序列化操作，同时可以考虑引入专门的DTO（数据转换对象）来协助数据转换。
不分层
如果不进行架构分层，可以吗？
不分层，在不断堆积的业务模块里，将导致各种复杂的依赖关系，且后续维护难度可能加大，代码冗余，且很容易产生牵一发而动全身的问题。
分层目标
架构分层的目标：“高内聚，低耦合”
- 高内聚：划分模块，然后让每一层都专注处理相关事情，从而简化系统的设计
- 低耦合：层与层之间通过接口或 API 进行交互，依赖方不用知道被依赖者实现细节
- 复用：分层后相关业务或模块都可以被复用
- 扩展性：分层架构可以让代码更容易横向扩展，维护
