软件开发要干什么：
反映真实世界要自动化的业务流程
解决现实问题
领域Domain
Domain特指软件关注的领域
在不能充分了解业务领域的情况下是不可能做出一
软件开发要干什么：
反映真实世界要自动化的业务流程
解决现实问题
领域Domain
Domain特指软件关注的领域
在不能充分了解业务领域的情况下是不可能做出一个好的软件
领域建模
领域模型驱动设计
- 分层架构
- 实体
- 值对象
- 服务
- 模块
- 聚合
- 工厂
- 资源库
分层架构：
- 将领域模型相关的代码集中到一个层中，把它从用户界面、应用和基础设施代码中分隔开来
- 释放领域对象的显示自己、保存自己、管理应用任务等职责，让它专注于展现领域模型
- 复杂的程序切分成层
- 层中采用内聚的设计
- 层仅依赖于它底下的那层
实体entity：有一类对象拥有唯一标识符
- 能够跨越系统的生命周期甚至能超越软件系统的一系列的延续性和标识符
- 这样的对象称为实体。
- 对某个对象是什么不感兴趣，只关心它拥有的属性
- 用来描述领域的特殊方面、且没有标识符的一个对象，叫做值对象
- 能被简单的创建和丢弃，生命周期中不会被持久化
- 值对象可以被共享，值对象应该不可变
- 领域中的一些动词，代表了领域中的一个重要的行为，却不属于任何对象
- 服务执行的操作涉及一个领域概念，这个领域概念通常不属于一个实体或者值对象
- 被执行的操作涉及到领域中的其他的对象
- 操作是无状态的
- 服务对象不再拥有内置的状态
- 服务对象担当重要的协调功能
- 开发通用语言时，领域中的主要概念被引入到语言中，语言中的名词很容易被映射成对象。
模块
- 将相关领域模型提炼分类，分而治之
- 将高关联度的模型分组到一个模块以提供尽可能大的内聚（以能完整完成任务为准）
- 分层是水平划分
- 模块是垂直划分(Domain内部)
参考架构概述
- 领域驱动设计(DomainDriven Design)有一个官方的sample工程，名为DDDSample
- 官网：http://dddsample.sourceforge.net/
- 该工程给出了一种实践领域驱动设计的参考架构
架构概述
详细架构
架构详解:Interfaces-接口层
- 该层包含与其他系统进行交互的接口与通信设施，在多数应用里
- 可能提供包括WebServices、RMI或Rest等在内的一种或多种通信接口
- 该层主要由Facade、DTO和Assembler三类组件构成，三类组件均是典型的J2EE模式
- DTO- DataTransfer Object（数据传输对象），也常被称作VO-ValueObject(值对象)
- DTO设计之初是为了将细粒度的领域对象包装为粗粒度的数据结构，减少网络通信并简化调用接口
DTO 作用
- 减少网络流量
- 简化远程对象和远程接口
- 传输更多的数据减少远程调用次数
- 避免将领域状态跨层次传递
- 由于同步和版本控制增加了复杂性
Assembler
- DTO与领域对象之间的相互转换工作多由Assembler承担
- 因此Assembler几乎总是同DTO一起出现。
Façade
- 实践Facade的过程中最难把握的问题就是Facade的粒度问题。
- 传统的Service均以实体为单位进行组织，而Facade应该具有更粗粒度的组织依据，较为合适的粒度依据有：
- 一个高度内聚的模块一个Facade
- 或者是一个“聚合”(特指领域驱动设计)一个Facade.
Facade 应用时序图
Service
Service会与多种组件进行交互，这些组件包括：
- 其他的Service
- 领域对象
- Repository
- DAO
Domain-领域层
} Domain层是整个系统的核心层，该层维护一个使用面向对象技术实现的领域模型，几乎全部的业务逻辑会在该层实现
} Domain层包含:
◦ Entity（实体）
◦ ValueObject(值对象)
◦ Domain Event（领域事件）
◦ Repository（仓储）等
Infrastructure-基础设施层
- 基础设施层nfrastructure为Interfaces、Application和Domain三层提供支撑
- 所有与具体平台、框架相关的实现会在Infrastructure中提供，避免三层特别是Domain层掺杂进这些实现，从而“污染”领域模型
- Infrastructure中最常见的一类设施是对象持久化的具体实现
DDD && SOA
- DDD 领域模型驱动设计
- SOA 面向服务的架构
