应用层
把领域层划分出来
关联
至少有3种方法可以使得关联更易于控制
规定一个遍历方向
添加一个限定符, 以便有效地减少多重关联
消除不必要的关联
entity
要由标识定义的对象被称entity
value object
不关心使用的是VALUE OBJECT的哪个实例,只关心一个模型元素的属性时, 应把它归类为VALUE OBJECT
在设计VALUE OBJECT时有多种选择, 包括复制、共享或保持VALUE OBJECT不变
service
SERVICE是作为接口提供的一种操作, 强调的是与其他对象的关系
参数和结果应该是领域对象
好的SERVICE有以下3个特征
与领域概念相关的操作不是ENTITY或VALUE OBJECT的一个自然组成部分
接口是根据领域模型的其他元素定义的。
操作是无状态的
应用层service不包含业务(如发邮件),领域层service涉及业务(账户之间的转账)
module(package)
MODULE的选择应该取决于被划分到模块中的对象的意义
aggregate
需要用一个抽象来封装模型中的引用。AGGREGATE就是一组相关对象的集合，我们把它作为数据修改的单元。
每个AGGREGATE都有一个根（root）和一个边界（boundary）
边界定义了AGGREGATE的内部都有什么。根则是AGGREGATE所包含的一个特定ENTITY
只有AGGREGATE的根才能直接通过数据库查询获取。所有其他对象必须通过遍历关联来发现
factory
与FACTORY的一次交互中把创建对象所需的所有信息传递给FACTORY
同时必须确定当创建失败时将执行什么操作,比如某些固定规则没有被满足. 可以抛出一个异常或仅仅返回null
为了保持一致,可以考虑采用编码标准来处理所有FACTORY的失败
repository
REPOSITORY将某种类型的所有对象表示为一个概念集合
具有更复杂的查询功能, 将所有对象的存储和访问操作交给REPOSITORY来完成
handle event
Handling Event是一个抽象，它可以把各种具体的Handling Event类封装起来
通过在基类（Handling Event）中为每个类型添加FACTORY METHOD，可以将实例创建的工作抽象出来，这样客户就不必了解实现的知识
柔性设计
通用语言
释意接口
无副作用函数
断言
概念轮廓
独立的类
闭合操作
声明式设计
将隐式概念转变为显式概念
specification
设计模式应用于模型
策略模式
组合模式
重构
通过重构得到更深层次的理解
上下文映射
边界上下文
保持模型的完整性
共享内核
客户/供应商关系
各行其道模式
开发主机服务
防护层
核心域
通用子域
抽象核心
大型结构
演化
系统隐喻
职责层
知识级别
可插拔组件框架