业务对象模型:业务逻辑流转的过程中需要的所有角色,甚至包括业务逻辑流转本身。
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 基础公共模块等
四色建模法
-
时标对象
-
参与方
-
角色对象
-
描述对象