领域驱动设计概念
什么是DDD
- 领域（模型）驱动设计的缩写
- 一种指导复杂软件如何构建的方法论
- 以治理复杂度为目标的软件构件方法
- 是一种指导面向对象程序设计的具体方法
- 领域：即业务知识，包含问题域和解空间
- 模型：对客观事物的选择性描述，简化掉不必要的信息，抽象出对解决问题有价值的知识
- 领域模型：对业务概念和业务规则的抽象，最终表达为，类型，对象，属性和行为
- 驱动：最先思考的对象，最先考虑的问题，最先满足的目标，以xxx为核心
以业务知识为核心抽象出领域模型，用来指导软件构件过程，以治理复杂度为目标的方法
为什么需要DDD
- 治理微服务的落地，提供一种拆分微服务的指导方法
- 治理软件的复杂性，得到技术/业务/管理三者综合权衡下的更好设计
- 技术复杂度：延迟、吞吐、可靠、一致性、成本（机器资源，人力成本）
- 业务复杂度：业务目标（产品&商业&增长），交付周期
- 管理复杂度：团队规模，协作成本，人员流动，人均产出
上述目标相互影响，在有限的资源下相互矛盾，综合造成了软件开发的整体复杂性，而使用DDD可以综合考虑三种复杂度，在三者之间获得最佳平衡的架构设计。所以，DDD为我们提供了一种在软件构件过程中拆解问题，权衡利弊的一种实践。
DDD适用于业务密集型系统的设计！
名次解释
- 领域专家：产品&运营&顾问，对该业务领域具有深刻认识到人，掌握足够的领域知识的人
- 统一语言：领域专家和开发团队等等角色之间对关键概念建立统一的定义，消除沟通歧义
- 界限上下文：界限是一种评判标准，上下文强调的是对知识的隐藏，可以把微服务等驾驭界限上下文，一个界限上下文划分出一个自治单元，具有最小完备性，自我履行，独立进化，稳定空间四个特点，因此界限上下文对应着一套微服务，也对应一个技术团队
- UP(U)上游：特指被调用方，提供能力的被调用方
- Down(D)下游：特指调用者，使用上游能力解决问题的角色
- 上下文映射：具有上下文之间的依赖关系，也反应了团队直接的协作关系
- 实体：具有唯一标识符的对象
- 值对象：不具有唯一标识符需要依赖实体存在的对象
- 聚合：持有一些相互强协同的实体之间的引用，通过标识符引用实体
- 聚合根：唯一能对外引用的句柄，任何外部访问聚合内的实体，都需要通过聚合根对象，其他聚合也仅能通过聚合根引用其他聚合
- 工厂：就是工厂模式，用来创建并管理复杂聚合的创建与销毁
- 资源库：负责统一管理一个聚合的增删改查行为以及状态的变更，工厂和资源库实现对聚合对象生命周期的管理
- 领域服务：业务功能需要通过多个聚合之间相互协作才能完成，在聚合之上需要一个服务实现对聚合对象生命周期的管理
- 应用服务：领域服务关注整体业务的横向能力建设，引用服务关注的是对横向领域服务的协调与驱动，为完成某个业务功能，协调领域服务最终交付
- 基础设施：所有的技术实现细节都被隐藏在基础设施中
- 领域事件：主语+定语，所描述的在领域内的客观事实，公式：产生事件的对象名称+完成对象的过去式
- 角色命令：有某种角色，触发了某种命令，发生了某种领域事件
- 问题空间(域)：业务领域中的客观事实以及期望目标的统称
- 解空间(域)：解决问题的技术实现
- 分层架构：用户界面层，应用层，领域层，基础设施层