领域驱动设计

模型-->范式-->设计

领域知识
通用语言
模型演化
深层模型
隐藏概念

建模
文档
解释性模型
代码是模型的表达

分层架构
给复杂的应用程序分层,在每一层内分别进行设计,领域层与基础设施层以及用户界面层分离

软件中所表示的模型
entity(reference object) 某种具有连续性和标识的事物(定义为标识)
valueobject 描述某种状态的属性
service 无状态

关联
规定一个遍历方向
添加一个限定符
消除不必要的关联
关联使模型更精确

entity(引用对象)
标识(能够区分对象的属性)
标识问题取决于模型的特定方面
仅在真正需要的地方进行特殊处理

valueobject
用于描述领域的某个方面而本身没有概念标识的对象称为valueobject
表示设计元素,只关心是什么,不关心是谁
经常作为参数在对象之间传递消息,常常是临时对象
值对象的对象属性不可变,可变就不能共享
复制与共享
值对象之间的双向关联没有意义

service
操作从概念上讲不属于任何对象
Manager之类的名称结尾
与领域概念相关的操作不是实体或值对象
接口是根据领域模型的其他元素定义的
操作是无状态的
领域层的操作具有业务意义
区分应用层服务和领域层服务

module
相关职责的对象元素聚合到一起

建模范式
面向对象

管理对象生命周期
在整个生命周期中维护完整性
防止模型陷入管理生命周期复杂性造成的困境中

aggregate(聚合)
划定范围
根和边界
外部对象只可以引用根,而边界内部的对象之间则可以互相引用
内部所应用的固定规则必须得到满足

factory(工厂)
如果创建工作很复杂或者暴露了过多的内部结构
复杂对象,对象的功能和生成不会同时发生
工厂方法/抽象工厂/构建器
不要在构造函数中调用其他类的构造函数

repostitory(存储库)
对象与存储之间的相互转换
使用已存储的数据创建实例的过程称为重建
对值的全局访问,如枚举
repository将某种类型的所有与对象表示为一个概念集合,它的行为类似于集合.负责对象和数据库交互
可用来获取持久化对象并管理它们的生命周期
使应用程序和领域设计与持久化技术解耦
基于soecification的查询
数据库与模型之间的同步

引入应用层
应用层负责提问,领域层负责回答

在一些关联上对遍历方向进行了约束
循环引用在设计中有时是必要的,但他们维护起来很复杂
应该避免把必须同步的信息保存在两个不同的地方

用构造函数或工厂来创建关联对象
模型内部进行修改和折中

引入新特性
分析模式
性能优化

重构
找到深层次的模型
应用设计原则和模式来满足应用程序和开发人员自身需求的设计

复杂巧妙的领域模型是可以实现的，也是值得我们去花费力气实现的
这样的模型离开不断的重构是很难开发出来的，重构需要领域专家和热爱 学习领域知识的开发人员密切参与进来
要实现并有效地运用模型，需要精通设计技巧

为实现更深层模型而进行的重构
代码细节重构

柔性设计

突破
一系列微小的重构会逐渐汇聚成深层模型

专注于知识消化过程,逐渐建立健壮的通用语言,寻找那些重要的领域概念

将隐式概念转变为显示概念
深层模型包含了领域的核心概念和抽象
基本概念 ---> 精华
倾听领域专家的语言
寻找领域深层模型(抽象概念)

约束扰乱宿主对象
计算约束所需的数据从定义上看并不属于这个对象
相关规则在多个对象中出现
约束隐藏在了过程代码中
规格

为特殊目的创建谓词形式的显式的值对象,规格就是一个谓词,可用来确定对象是否满足某些标准

规格模式
规格封装了相同的规则

访问者模式
设计技巧

模式

intention-revealing-interfaces(意图接口)
释义接口(类和方法的命名能知道他的意图)

side-effect-free-function(无副作用函数)
任何对未来操作产生影响的系统状态改变都可以称为副作用
可以把命令和查询严格地放在不同的操作中。确保导致状态改变的方法不返回领域数据，并尽可能保持简单。
在不引起任何可观测到的 副作用的方法中执行所有查询和计算
把程序的逻辑放到函数中

assertion(断言)
编写测试类

conceptual contour(概念轮廓)
考虑粒度是在那种场合下使用的
高内聚低耦合

standalone class(独立的类)
概念过载的问题
消除不重要的依赖
尽力把最复杂的计算提取到独立的类中,实现此目的的一种方法是从存在大量依赖的类中将值对象建模出来

closure of operation(闭合操作)
减少依赖性的同事保持丰富接口的技术
定义操作时让它的返回类型与其参数的类型相同

声明式设计
代码生产技术破坏了迭代循环
规格由谓词的形式化概念演化而来
规格组合也是闭合操作
规格通用,可以抽象成抽象类或接口

分隔子领域
尽可能利用已有的形式

柔性设计在很大程度上取决于详细的建模和设计决策。
深层模型和柔性设计必须学习大量领域知识并 进行充分的讨论，还需要经历大量的尝试和失败

分析模式是一种概念集合,用来表示业务建模中的常见结构,它可能只与一个领域有关,也可能跨越多个领域
用来指导设计特定领域中的模型

将设计模式应用于模型
从代码的角度来看它们是技术设计模式,从模型的角度来看它们就是概念模式

策略(strategy)
把过程中极易发生变化的部分与那些更稳定的部分分离开

组合(composite)
将对象组织为树来表示部分整体的层次结构
设计模式应该仅仅在需要的时候才使用

通过重构得到更深层的理解
1,以领域为本
2,用一种不同的方式来看待事物
3,始终坚持与领域专家对话

同时处理模型关注点和设计关注点

柔性设计主要通过减少依赖性和副作用来减轻人们的思考负担
只有那些对用户最重要的部分才具有较细的粒度
那些经常需要修改的地方能够保持很高的灵活性

持续重构

保持模型的完整性
大模型,策略往往是把设计和策略综合到一起的结果

限界上下文
BOUNDED CONTEXT

持续集成
CONTINUOUS INTEGRATION
模型概念的集成
现实的集成

重复的概念和假同源

自动测试套件

上下文地图

SHARED KERNEL是两个高度协调的团队之间的合作模式
CUSTOMER/SUPPLIER TEAM(上下游协作)的跟随者模型则是应对与一个对合作不感兴趣的团队进行集成

反腐层
外观facade
适配adapter

子系统与大量其他系统进行集成时,可以设计出一个协议,把子系统作为一组service供其他系统访问

合并上下文
选择小的子域开始
shared kernel

管理大模型的复杂性

精炼
core domain(核心域)
整体设计视图
选择核心

generic subdomain(通用子域)
doamin vision statement(领域愿景说明)
highlighted core(突出核心)
精炼文档
标记核心
cohesive mechanism(内聚机制)
segregated core(分离的核心)  abstract core(抽象核心)

大型结构
整体视图
组织原则
evolving order(演化有序,整体结构)
system metapjor(系统隐喻)
responsibility layer(职责分层)
决策层
策略层
作业层
潜能层
knowledge level(知识级别)
pluggable component framework(可插入式组件框架)