架构学习-DDD补充

142 阅读3分钟

领域模型指导程序设计

将领域模型映射到程序中

服务

标识的是在领域对象之外的操作和行为,接收用户请求和执行某些操作. 当用户在系统界面中进行操作时,会向系统发送请求"服务"去接收用户的这些请求,然后根据需求去执行相应的方法,所有的操作完成后,再将实体或值对象中的数据持久化到数据库中.

实体

通过一个唯一标识字段来区分真实世界中的每一个个体的领域对象.如学籍中的学员,通过学号来区分每个人,每个学员有自己的年龄和姓名属性,这些属性随时间变化而变化.

值对象

代表的是真实世界中那些一成不变,本质性的事务,这样的领域对象叫作"值对象".如地理位置,经纬度.

实体与值对象的区别

可变性是实体的特点,不变性是值对象的本质.比如宫保鸡丁这道菜,可以设计成实体,也可以设计成值对象.如果是实体,每个店的宫保鸡丁都是不一样的,如果是值对象,所有餐厅的宫保鸡丁都是一样的.

贫血模型与充血模型的使用场景

将需要封装的业务逻辑放到领域对象中,按照充血模型去设计.除此之外的其他业务逻辑放到service中,按照贫血模型去设计.

需按照充血模型封装的业务逻辑

  • 在领域模型中出现了类似继承,多态的情况
  • 在软件设计的过程中需要将一些类型或者编码进行转换
  • 表现领域对象直接的关系,如查询订单的时候展示订单与人的关系,订单与订单明细的关系
  • "聚合",在真实世界中那些代表整体与部分的事务

聚合,仓库与工厂

聚合:表达的是真实世界中整体与部分的关系,如:订单与订单明细

  • 创建订单时将订单明细创建在订单中
  • 保存订单时同时保存订单表与订单明细表,并放在同一事务中
  • 查询订单时同时查询订单表与订单明细表,并将其装配成一个订单对象

image.png

  • 聚合体现的是一种整体与部分的关系,当整体不存在时,部分就变的没有意义了,就比如订单都不存在了,订单明细还有什么意义.
  • 在一个系统中,增删改的业务可以采用领域驱动设计,但在非增删改的分析汇总场景中,直接SQL查询.

DDD的工厂

创建聚合对象

  • 订单仓库将任务交给订单工厂,订单工厂分别调用订单DAO,订单明细DAO和用户DAO去进行查询
  • 将订单明细对象与用户对象,分别set到订单对象的"订单明细"与"用户"属性中
  • 订单工厂将装配好的订单对象返回给订单仓库

DDD的仓库

通过仓库与工厂,对原有的DAO进行了一层封装,在保存,装载,查询等操作中,加入聚合,装配等操作并将操作封装起来,对上层的客户程序屏蔽

限界上下文

一个复杂系统的领域驱动设计,是以子域为中心进行领域建模绘制出一张一张的领域模型设计,称之为限界上下文

单一职责原则

每个限界上下文中实现的都是软件变化同一个原因的业务,如下单这个操作就只在下单这个限界上下文中处理,用户信息的读取不应该在下单这个限界上下文中处理应该在用户信息上下文中处理