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