《领域驱动设计实践》由会员分享，可在线阅读，更多相关《领域驱动设计实践（109页珍藏版）》请在金锄头文库上搜索。
1、领域驱动设计实践 瑞友科技IT应用研究院池建强 Twitter sagacity Weibo 池建强 Mail jackychi About ME 池建强 70后程序员 98年毕业 先后就职于洪恩软件 RocketSofeware和用友集团 瑞友科技 现任瑞友科技IT应用 研究院副院长 先后从事互联网和企业应用开发 目前致力于基础应用平台 的研究 热爱技术和编码工作 坚持年轻时的理想 倒霉的乐观者 技术领域 Java Python Ruby Objective C DDD OSGi App Platform Domain Model What Why How 模型是抽象的 现实是形象的 技巧是
2、重要的 思想是永恒的 从软件系统诞生之 初 程序设计者就开始 梦想有 一天能够像建造 桥梁和房屋那样 透 明 的构造软件 让现 实和代码对应起来 软件开发总是比任何人估计的慢 如果不是有意 的放宽项目期限 几乎不会出现提前完成的软件项目 和产品 有时候我们必须耐下心来把所有琐碎的 困 难的 细节的问题都解决并不断打磨 才能完成 有 时候没有别的办法 只能等待 一个案例 2010 012010 03 2010 05 2010 12 采用领域驱动的 方式开发 幸福的时光总是短暂的 2010 012010 03 2010 05 2010 12 商务要求尽快出 一 个版本 2010 012010 03
3、 2010 05 2011 04 好日子结束了 苦逼的总是开发者 采用领域驱动的 方式开发 领域驱动设计不是用来解决开发速度的 领域驱动设计是用来解决软件核心复杂性的 软件系统面向对象的设计思想可谓历史悠久 20世纪70 年代的Smalltalk可以说是面向对象语言的经典 直到今 天我们依然将这门语言视为面向对象语言的基础 面向对象是大部分语言的 一个基本特性 像C Java Objective C这样的静态语言 Ruby Python这 样的动态语言都是面向对象的语言 面向对象的分析设计 2004年著名建模专家Eric Evans发表了他最具影响力的书籍 Domain Driven Desi
4、gn Tackling Complexity in the Heart of Software 中文译名 领域驱动设计 软件核心复杂性应对之道 书中 提出了 领域驱动设计 简称 DDD 的概念 领域驱动设计事实上针对是OOAD的 一个扩展和延伸 DDD 基于面向对象分析与设计技术 对技术框架进行了分层规 划 同时对每个类进行了策略和类型的划分 采用DDD的设计思想 业务逻辑不再集中在几个大型 的类上 而是由大量相对小的领域对象 类 组成 这 些类具备自己的状态和行为 每个类是相对完整的独立 体 并与现实领域的业务对象映射 领域模型就是由这 样许多的细粒度的类组成 领域驱动设计是技术人员和领域专
5、家沟通的桥梁 技术人员和领域专家沟通的桥梁是领域驱动设计 技术人员 领域驱动设计 沟通 领域专家 桥梁 public interface IBookService double submitOrder int orderId 不容易理解的抽象 public interface IBookService double submitOrder Order order 抽象 打折策略 领域模型和事务脚本 事务脚本 Transaction Script 的核心是过程 每个过程处理来 自表现层的单个请求 大部分业务应用都可以被看成 一系列事务 从某种程度上来说 通过事务脚本处理业务 就像执行 一条条Sq
6、l 语句来实现数据库信息的处理 事务脚本 Transaction Script 的核心是过程 每个过程处理来 自表现层的单个请求 大部分业务应用都可以被看成 一系列事务 从某种程度上来说 通过事务脚本处理业务 就像执行 一条条Sql 语句来实现数据库信息的处理 事务脚本把业务逻辑组织成单个过程 在过程中直接调用数据库 业务逻辑在服务 Service 层处理 Action处理UI层的动作请求 将Request中的数据组装后传递给 BusinessService BS层做简单的逻辑处理后 调用数据访问对 象进行数据持久化 其中VO充当了数据传输对象的作用 只具 备getter和setter方法 没
7、有状态和行为 Transaction Script 效果 后果 看代码 事务脚本模式的特点是简单容易理解 面向过程设计 事务脚本模式的特点是简单容易理解 面向过程设计 对于少量逻辑的业务应用来说 事务脚本模式简单自然 性能良 好 容易理解 而且 一个事务的处理不会影响其他事务 事务脚本模式的特点是简单容易理解 面向过程设计 对于少量逻辑的业务应用来说 事务脚本模式简单自然 性能良 好 容易理解 而且 一个事务的处理不会影响其他事务 不过缺点也很明显 对于复杂的业务逻辑处理力不从心 难以保 持良好的设计 事务之间的冗余代码不断增多 通过复制粘贴方式 进行复用 可维护性和扩展性变差 Smart U
8、I 反模式 在用户界面中实现大部分业务逻辑 领域模型 Domain Model 面向对象分析和设计 领域模型具备自己的属性行为状态 并与现实世界的业务对象相映射 各类具备明确的职责划分 领域对象元素之间通过聚合和引用等关系配 合解决实际业务应用和规则 可复用 可维护 易扩展 可以采用合适的设计模型进行详细设计 要求设计人员有良好的抽象能力 Domain Model 我们也来看代码 在实际的设计中 我们需要根据具体的需求选择相应 的设计模式 具备复杂业务逻辑的核心业务系统适合 使用领域模型 简单的信息管理系统或大数据处理可 以考虑采用事务脚本模式 领域驱动设计元素 成熟 清晰的分层架构 领域对象
9、与现实世界的业务映射 明确的职责划分 分层架构 领域对象是核心 领域对象复用 完整的业务对象描述 设计复用 设计基于领域对象而非数据库 复用 具备复杂业务逻辑的软件开发 对设计和开发人员要求较高 不适用普通CRUD的业务 软件的维护性和扩展性良好 使用场景 分层架构 名称职责 展现层负责向用户展现信息以及解释用户命令 应用层 很薄的 一层 用来协调应用的活动 它不包含业务逻辑 它不保留 业务对象的状态 但它保有应用任务的进度状态 领域层 本层包含关于领域的信息 这是业务软件的核心所在 在这里保留 业务对象的状态 对业务对象和它们状态的持久化被委托给了基础 设施层 基础设施层 本层作为其他层的支
10、撑库存在 它提供了层间的通信 实现对业务 对象的持久化 包含对用户界面层的支撑库等作用 实体 值对象 服务 En ty 实体 人 座位 先到先得 Value Object 值对象 画笔 地址 name name Services 服务 Entities 具备唯 一ID 能够被持久化 具备业务逻辑 对应现实 世界业务对象 Entities 具备唯 一ID 能够被持久化 具备业务逻辑 对应现实 世界业务对象 Value objects 不具有唯 一ID 由对象的属性描述 一般为临时 对象 可以用来传递参数或作为实体的属性 也可以封装复杂的 计算逻辑 Entities 具备唯 一ID 能够被持久化
11、具备业务逻辑 对应现实 世界业务对象 Value objects 不具有唯 一ID 由对象的属性描述 一般为临时 对象 可以用来传递参数或作为实体的属性 也可以封装复杂的 计算逻辑 Services 为上层建筑提供可操作的接口 负责对领域对象进行 调度和封装 同时可以对外提供各种形式的服务 领域模型的生命周期 活动状态数据库 数据库或文件 创建 存储 重建 归档 删除 删除 修改 关系数据库 面向对象数据库 NoSql Factory和Repository基于Aggregate 对特 定生命周期转换的复杂性进行了封装 Aggregate 聚合 什么是聚合 我们来画 一下 Aggregate r
12、oot ItemProduct CashPayCreditCardPay Factory IoC public Driver private ICar car public Driver public void drive car method getter and setter Driver drive helper getBean oneDriver drive drive Repository 操作持久对象并管理其生命周期 领域对象和持久化解藕 封装持久化技术 多数据源 连接池 数据源访问代理 O R Mapping技术 NoSql 分布式文件系统 持久化层可替换 来自QCon淘宝的分享
13、 规则引擎的案例 领域元素 Package 规则包 Rule 规则 Attribute 规则属性 When Then 条件 如何实现这样 一个设计呢 看例子吧 一些原则 表意接口 Inten on Revealing Interface 如果 一个开发人员为了使用 一个组件必须要去研究 它的实现 那么就失去了封装的意义 无副作用函数 Side Eff ect Free Func on 所谓 副作用 side effect 指的是函数内部与外部互动 最典型的情况 就是修改全局变量的值 产生运算以外 的其他结果 函数式编程 所谓 副作用 side effect 指的是函数内部与外部互动 最典型的情
14、况 就是修改全局变量的值 产生运算以外 的其他结果 函数式编程 利用VO的不变性 创建无副作用的函数 例如 传入或返回 的对象是by value 而不是by reference 对返回值的修 改 不会影响原来的对象 Conceptual Contour 概念轮廓 通过坝或其他手段把 一个湖分割为几块 在任何 一块中投入 石子都不会影响其他部分 把设计元素 行为 接口 类 聚合等 分解为内聚单元 通过重构 找出模型中经常变化的部分和基本稳定的部分 如何实现组件之间的解耦 ESB也是 一种方式 但是远程调用 事务 设计时需要慎重选择 小结 一 表意接口把对象描述成有意义的单元 无副作用函数让我们可
15、以安全的使用这些单元 概念轮廓让这些单元更稳定 更符合直觉 更容易组合 小结二 低耦合是对象设计的 一个基本要素 尽可能保持低耦合 把其他所 有无关的概念提取到对象之外 消除所有不重要的依赖 限制交叉依赖的方法 1 子系统 2 模块化 3 聚合 4 单向关联 领域模式 Specifi ca ons 规约是 一种布尔断言 规约是业务规则的 一部分 理论上规约类中的方法只有 一个 IsSatisifedBy Object 规约用来测试对象是否满足某种条件 用来进行对象查询 也可以作为某个对象的创建条件 单 一规约规则 多个规约通过组合表现复杂的规约 public class BookShelf p
16、rivate List books public BookShelf books new ArrayList public void addBook Book book books add book 增加规约 1 不同作者的书放到相应 的书架 2 不同类型的书放到相应 的书架 引入规约 public class AuthorSpecification implements Specification private String author public AuthorSpecification String author this author author public boolean isSatisfiedBy Book book return book getAuthor equals author public void addBook Book book if validate book books add book private boolean validate Book book AuthorSpecification as new AuthorSpecificati
