DDD领域驱动设计/模型详解

什么是领域驱动设计（Domain Driven Design）？

简称：DDD是一种架构思想。是一套应对复杂软件系统分析和设计的面向对象建模方法论。  是一种软件开发方法。

为什么需要领域驱动设计

  开发工程师是通过软件来解决问题，编写代码只是其中的一部分工作，设计和交流同样重要。领域驱动设计的目的是让软件系统在实现时准确的基于对真实业务过程的建模并根据真实的业务过程的调整而调整。

领域驱动设计的两个阶段

 1. 领域通用语言
     以一种领域专家、设计人员、开发人员都能理解的通用语言作为相关交流的工具。在交流的过程中发现领域概念，并将这些概念设计成一个领域模型。
 2. 将领域模型转换为代码
     由领域模型驱动软件设计，用代码来实现领域模型，从而确定业务边界和应用边界，保证业务模型和代码模型的一致性

领域驱动设计和领域模型之间的关系？

  领域驱动设计的核心是建立正确的领域模型。

领域驱动设计分层架构

展现层（Interface）又叫UI层，用户界面。负责与前端交互进行界面展示。主要用来处理用户发送的请求，并将数据传递给应用层。数据的组装、数据传输格式以及Facade（“门面”）接口等代码都会放在这层目录里。
应用层（Application Layer）:负责业务流程，但不包含业务逻辑
领域层（Domain Layer）:负责表达业务概念，业务状态信息以及业务规则，是业务软件的核心
基建层（Infrastructure Laye）:又叫基础设施层，负责为其他层提供通用的技术能力，提供层间的通信，为领域层实现持久化基础。
总之，基础设施层可以通过架构和框架来支持其他层的技术需求；
分类的依据是：越往上，预期变动越频察；越往下，预期变动越少。

什么是领域模型？

又叫概念模型，领域对象模型，分析对象模型。
领域模型是一套完整，详尽的方法论。是对领域内的概念类或现实世界中对象的可视化表示。
目的：专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。如从如何需求沟通（构建领域知识），到高层设计（战略建模），详细设计（战术建模），细致到代码的实现风格都给出了示例。

为什么要建模

通用”是建模的第一步。“复用”将模型达成一致。
第一：  把心智模型提取出来，显性化，让不同的人对业务的理解达成一致。
第二： 建模本质上是一种抽象。抽象就是归类。目的是减轻认知负担，避免重复的思考和工作，提升人的计算能力。归类复用，避免重复的工作，让人可以关注更高层面的事务

怎么建模才合理

判断模型好坏的重要依据是它的使用效率（扩展度、灵活度、与组织的对应度）

四种领域模型

失血模型：只有getter和setter方法的实体类，所有的业务逻辑完全由Service层来完成
贫血模型：领域对象里包含包含了不依赖于持久化的原子领域逻辑，而组合逻辑在Service层   
充血模型：绝大多业务逻辑都放在领域对象里，包括持久化逻辑，而Sevice是很薄的一层，仅仅封装事务和少业务逻辑，不和Dao层打交道。
胀血模型：去掉Service层，只保留领域对象。