DDD入门
DDD的理解
领域模型(domain model)是对
领域内的概念类或现实世界中对象的可视化表示。领域模型也称为 概念模型、领域对象模型和分析对象模型。
在传统的架构设计中，经常针对⼀些功能点争论“这个功能不应该我改，应该是你那边改”，最终被妥协改了之后都改不明⽩为什么这个功能要在⾃⼰这边改。领域驱动设计（DDD）也许在这个时候能帮助你做到清晰的划分。
什么是DDD
领域驱动设计最初是由Eric Evans 提出来的，但是多年以后一直停留在理念阶段，真正能实现并落地的项目和公司少之又少。它主要帮助我们解决传统单体式集中架构难以快速响应业务需求落地的问题。
DDD作用
-
统一思想
统一项目各方业务，产品，开发对问题的认知，而不是开发和产品统一，业务又和产品统一而且产生分歧
-
明确分工
领域模型需要明确定义来解决方方面面的问题，而针对这些问题则形成了团队自己的理解
-
反映变化
需求是不断变化的，因此我们的模型也是在不断的变化的。领域模型则可以真实的反映这些变化
-
边界分离
领域模型与数据模型分离，用领域模型来界定哪些需求在什么地方实现，保持结构清晰。
DDD的概念
实体
有唯一标志的核心领域对象，且这个标志在整个软件生命周期中都不会发送变化。这个概念和我们软件模型中和数据对应的模型(Entity)实例比较接近，唯一不同的是DDD中这些实体会包含与该实体相关的业务逻辑，它是操作行为的载体
值对象
依附于实体存在，通过对象属性来标识的对象，他将一些相关的实体属性打包在一起处理，形成一个新的对象
聚合
实体和值对象表现的是个体能力，而我们的业务逻辑往往比较复杂，依赖个体是无法完成的，这个时候需要多个实体和值对象一起协同工作，而这个协同的组织就是聚合。聚合是数据修改和持久化的基本单元，同一个聚合内要保证事务的一致性，所以在设计的时候要保证聚合的设计拆分到最小化以保证效率和性能
聚合根
也叫做根实体，一个特殊的实体，它是聚合的管理者，代表聚合的入口，抓住聚合根可以抓住整个聚合
领域服务
有些领域的操作是一些动词，并不能简单的把它们归类到某个实体或者值对象中。这样的行为从领域中识别出来之后应该将它声明成一个服务，他的作用仅仅是为领域提供相应的功能。
领域事件
在特定的领域由用户动作触发，表示发生在过去的事件。
DDD的四种模型
-
失血模型
模型中只有简单的get,set方法，是对一个实体最简单的封装，其他所有的业务行为由服务类来完成。
-
贫血模型
在失血模型基础之上聚合了业务领域行为，领域对象的状态变化停留在内存层面，不关心数据持久化。意思是增加一些业务逻辑
-
充血模型
在贫血模型基础上，负责数据的持久化，增加保存数据的方法。依赖于操作数据的持久化的类。
-
胀血模型
service都不需要，所有的业务逻辑，数据存储都放到一个类中。
总结:
对于DDD来说，失血和胀血都是不合适的，失血太轻量没有聚合，胀血是初学者才这样写代码。充血模型依赖数据持久化接口，与数据存储紧密相关，有破坏程序稳定性的风险。
DDD的建模方法
用例分析法
用例分析法是领域建模最简单可行的方式。大致可以分为获取用例，收集实体，添加关联，添加属性，模型精化几个步骤。
- 获取用例： 提取领域规则描述
- 收集实体: 定位实体
- 添加关系：两个实体间用动词关联起来
- 添加属性： 获取实体属性
- 模型精化: 可选的步骤，可以用UML的泛化和组合来表达模型间的关系，同时可以做子领域的划分
四色建模法
四色建模法是一种模型的分析和设计方法，通过把所有模型分为四种类型，帮助模型做到清晰，可追溯。简单来说，四色关注的是某个人的角色在某个地点的角色用某个东西做了某些事情。
事件风暴法
事件风暴类似头脑风暴，简单来说就是谁在何时基于什么做了什么，产生了什么，影响了什么事情。
架构分层
上图是传统架构分层和领域模型分层的对比。
DDD分层发生了一些变化：
Application: 包含事件注册，业务逻辑等
Domain: 聚合，实体，值对象
InfraStructure: 基础设施封装，数据库访问等。
以上就是DDD的简单入门，后续我会写一些DDD实战相关的文章，欢迎大家多多指教。