$ 《领域驱动设计精粹》笔记

$ 目录

第1章

  • 有效设计
  • 战略设计
  • 战术设计

第2章 运用限界上下文与通用语言进行战略设计

第3章 运用子域进行战略设计

  • 子域类型
  • 应对复杂性

第4章 运用上下文映射进行战略设计

  • 映射的种类
    • 合作关系
    • 共享内核
    • 客户-供应商
    • 跟随者
    • 防腐层
    • 开放主机服务
    • 已发布语言
    • 各行其道
    • 大泥球
  • 善用上下文映射
    • 基于SOAP的RPC
    • RESTful HTTP
    • 消息机制

第5章 运用聚合进行战术设计

  • 聚合的经验法则
    • 规则一:在聚合的边界内保护业务规则不变性
    • 规则二:聚合要设计的小巧
    • 规则三:只能通过标识符引用其他聚合
    • 规则四:利用最终一致性更新其他聚合
  • 建立聚合模型
    • 慎用贫血模型
    • 慎重选择抽象级别
    • 大小适合的聚合
    • 可测试的单元

第6章 运用领域事件进行战术设计

第7章 加速和管理工具

  • 事件风暴

$

Scrum

Scrum是迭代式增量软件开发过程,通常用于敏捷软件开发。

术语:

  • 角色
    • 产品负责人 Product Owner: 负责维护产品订单的人,代表利益相关者的利益。
    • Scrum主管 Scrum Master: 为Scrum过程负责的人,确保scrum的正确使用并使得Scrum的收益最大化。
    • 开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。
  • 工件
    • 产品列表 Product Backlog:根据用户价值进行优先级排序的高层需求。
    • 冲刺订单 Sprint Backlog:要在冲刺中完成的任务的清单。
    • 产品增量 Increment:最终交付给客户的内容
  • 活动
    • 计划会 Sprint Planning Meeting:在每个冲刺之初,由产品负责人讲解需求,并由开发团队进行估算的计划会议。
    • 每日立会 Daily Standup Meeting:团队每天进行沟通的内部短会,因一般只有15分钟且站立进行而得名。
    • 评审会 Review Meeting:在冲刺结束前给产品负责人演示并接受评价的会议。 反思会/回顾会 Retrospective Meeting:在冲刺结束后召开的关于自我持续改进的会议。
  • 其他
    • 冲刺 Sprint: 一个时间周期(通常在2周到1个月之间),开发团队会在此期间内完成所承诺的一组订单项的开发。

参考

使用scrum进行知识获取而不是控制交付节奏。

$ 第1章 概述

$ 战略设计

运用限界上下文的战略设计模式来分离领域模型

使用在明确的限界上下文中发展一套领域模型的通用语言。

通过子域处理遗留系统中无边界的复杂性

通过上下文映射集成多个限界上下文

$ 战术设计

聚合模式

DDD就是以最明确而又可行的方式对领域进行建模。

使用领域事件

$ 第2章

简单地说,DDD主要关注的是如何在明确的限界上下文中创建通用语言的模型。

限界上下文:是语义和语境上的边界,边界内的每个代表软件模型的组件都有特定的含义并处理特定的事务,这些组件都有特定的上下文语境和语义理据。

当限界上下文被当作组织的关键战略举措进行开发时,被称为核心域

架构模型:

  • 端口适配器架构
  • 事件驱动架构
  • CQRS:命令和查询职责分离
  • 响应式架构和Actor模型
  • REST:具象状态传输
  • SOA:面向服务的架构

$ 第3章

子域代表的是一个单一的、有逻辑的领域模型。项目中有三种主要的子域类型:

  • 核心域 战略投资
  • 支撑子域 定制开发
  • 通用子域 采购外包

限界上下文应该与子域一一对应。

$ 第4章

上下文映射:核心域必须和其他限界上下文进行集成。

$ 第5章

例子:

名为敏捷项目管理上下文的核心域和提供协作工具的支撑子域,它们使用上下文映射集成在一起。

实体:

  • 一个实体模型就是一个独立的事物。
  • 每个实体都有一个唯一的标识符。
  • 绝大多数时候实体是可变的。

值对象:

  • 是对一个不变的概念整体所建立的模型。
  • 它没有唯一标识符,而是由值类型封装的属性对比来决定相等性。
  • 常常被用来描述、量化或者测量一个实体。

聚合:

  • 由一个或多个实体组成,其中一个被称为聚合根。聚合的组成还可能包括值对象。
  • 每个聚合的根实体控制着所有聚集在其中的其他元素。
  • 每个聚合都会形成保证事务一致性的边界。

如何确定聚合的边界并避免出现臃肿的设计?一个有价值的设计方法:

  1. 每个聚合一开始创建时只允许包含一个实体,并把它作为聚合根。用关联最紧密的字段填充属性。
  2. 领域专家检查每个聚合发生变化时的影响范围。为每个聚合和它的一致性规则制作一个清单,和响应时间范围。
  3. 领域专家确定每个基于响应的更新可以等待的时间(即时,延时)。
  4. 对每一个即时发生的时间范围,把这两个实体合并到同一个聚合的边界内。
  5. 对于每一个在给定等待时间内更新的响应聚合,利用最终一致性更新其他聚合。

$ 解惑

  1. 实体或者值对象能在两个不同的聚合中重复出现吗?

  2. 实体或者值对象都是名词吗?

    对象一般是名词,服务一般是动词,服务一般还包括Manager

  3. 如何保证领域对象不泄露?

值对象能被简单的创建和丢弃,生命周期中不会被持久化

更新时间: 4/12/2020, 11:03:16 AM