写点什么

【第十周】学习笔记

用户头像
Aldaron
关注
发布于: 2020 年 08 月 12 日

DDD 领域驱动设计

核心解决问题:

解决问题方式:

为什么需要DDD(Why?)

项目情况:

  • 用户或产品经理的需求零散,不考虑功能的迭代

  • 工程师在维护代码时是自由式的累加,不考虑后续的维护

  • 软件系统只有需求分析没有系统设计,不考虑系统的演进

  • 功能特性不是按照领域模型内在的逻辑设计,而是按照各色人等自己的主观想象设计

从而导致:

  • 增加功能困难

  • 开发周期长

  • 线上问题频出

  • 需要重构来解决问题

开发模式

事务脚本的开发模式

(当前最普遍的开发方式)



分层:

  • Controller:控制层。负责功能的触发

  • Service:服务层。服务数据的读取,业务逻辑的处理

  • Dao:数据层。负责数据的存储与提供检索功能

问题:

  • 服务层为了满足业务需求会越来越臃肿

领域模型的开发模式



分层原则:每一个类需要完成自己所有的功能,再交给下一层进行处理

核心原则:面向对象

贫血模型 VS 充血模型

贫血模型:类中只有方法没有成员变量,而方法调用时传递的数值对象没有方法(或者只有简单的 Getter 和 Setter 方法),因此事务脚本又被称作贫血模型。

充血模型:类中合并了行为和数据的领域对象模型。通过领域对象的交互完成业务逻辑的实现,也就是说,设计好了领域对象,也就设计好了业务逻辑。这样实现的模型称为充血模型。

战略设计

领域

定义:是指一个组织所做的事情以及其包含的一切。就是组织的业务范围和做事方式,也是软件开发的目标范围。

核心目标:设计的系统与现实业务统一

子域

领域是一个组织所做的事情以及其包含的一切。分离关注点的原则指导我们需要将领域划分成多个子域。

限界上下文

在一个子域中,会创建一个概念上的领域边界,在边界中任何领域对象都只能表示特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文和子域具有一对一的关系,用来控制子域的边界,保证子域内的概念统一性。

通常限界上下文对应一个组件或一个模块,或者一个微服务,或者一个子系统。

上下文映射图

不同的限界上下文,也就是不同的子系统或者模块之间会有各种的交互合作。

DDD 使用上下文映射图来设计这种关联和交互



用户头像

Aldaron

关注

还未添加个人签名 2018.04.28 加入

还未添加个人简介

评论

发布
暂无评论
【第十周】学习笔记