【学习笔记】领域驱动设计相关

业务对象模型：业务逻辑流转的过程中需要的所有角色，甚至包括业务逻辑流转本身。

1.失血模型

特点：对象中只包含get set方法

优点：领域对象结构简单

缺点：

• 肿胀的业务代码

• 无法应对频繁更改的需求

2.贫血模型

固有行为：不用持久化的行为

非固有行为：需要跟数据库进行持久化交互的行为

优点：

• 层次结构清楚，各层级是单向依赖

• 对于只有少量业务逻辑的应用来说，使用起来非常自然

• 开发非常迅速，易于理解

缺点：无法良好地应对非常复杂的逻辑及场景

3.充血模型

优点：

• 更加符合面向对象原则

• 业务逻辑层很薄，符合单一职责原则

缺点：

• 职责不好划分，开发者水平要很高

• 模型中包含大量操作，实例化增加很多不必要的消耗

4.胀血模型

优点：

• 简化分层架构

• 符合面向对象原则

缺点：取消业务逻辑层，直接在domain Object上封装事务及授权，授权很多根本不属于这个领域对象的逻辑，模型不稳定。

MVC架构模式

缺陷

1.导致控制器冗余

2.控制器对于对象依赖过重

3.对象之间会产生耦合

4.由于Spring的存在，其实我们的开发是不符合面向对象的

DCI架构

对于MVC模式的补充 面向对象量化落地

Data 对象数据

Context 对象的场景

五层架构

• 用户界面层（User Interface）：处理用户发送的Restful请求，解析配置文件

• 应用层（Application）：进程管理 线程调度

• 环境层（Context）：领域与行为绑定，聚合

• 领域层（Domain）：领域模型，行为进行建立

• 基础设施层（Infrastructure）

聚合的边界划分设计原则

• 生命周期一致原则

• 问题域一致性原则

• 场景一致性原则

• 聚合 尽可能小

业务架构：领域建模 业务边界 沉淀

技术架构：服务治理 中间件 组件

分层架构设计就是为了帮助我们达到高内聚、低耦合复用性设计、拓展性设计

用户界面层：显示信息给用户 对外的model 模型转换

应用层：线程调度 应用服务 与模型进行与实体无关的业务逻辑

领域层：业务概念 规则 领域模型

基础实施层：交互层次

apis API接口层

• model 视图模型，数据模型定义vo/dto
• assembler 装配器，实现模型转换 apiModel -> domainModel
• controller 控制器，对外提供接口

application 应用层

• service 应用服务，非核心服务
• task 任务定义，协调领域模型
• others

domain 领域层

• common 公共代码抽取，限于领域层有效
• events 领域事件
• model 领域模型
• dict 领域划分的模块，可理解为子域划分

    - DictVo 领域值对象
    - DictEntity 领域实体，充血的领域模型，例如CRUD
    - DictAgg 领域聚合，通常表现为实体的聚合，需要有聚合根
    - DictService 领域服务，不能归于上述模型，如分页条件查询等可写在此处

• service 领域服务类，一些不能归属于某个具体领域模型的行为
• factory 工厂类，负责复杂领域对象创建，封装细节

infrastructure 基础设施层

• persistent 持久化机制

  - po 持久化对象
  - repository 仓储类，持久化接口&实现，可与ORM映射框架结合

• general 通用技术支持，向其他层输出通用服务

  - config 配置类
  - toolkit 工具类
  - common 基础公共模块等

四色建模法

• 时标对象

• 参与方

• 角色对象

• 描述对象