DDD初探
领域模型早期就是数据库设计
DDD是一种处理高度复杂领域的思想
分离技术实现的复杂性
DDD不是架构，是架构设计方法论
DDD通过边界划分，复杂的业务领域简单化，帮助设计出清晰的领域和应用边界
软件的架构模式：单机，集中式（面向对象），分布式微服务架构
DDD包含战略设计和战术设计
宏观：战略设计 业务战略上的重点，从业务角度触发，建立业务领域模型，花饭领路边界，建立通用语言的限界上下文
战术设计：技术角度触发，侧重领域模型的技术实现，完成开发和落地
学习DDD：
一套完整的项目系统的设计方法
有助于提高架构设计能力--->领域专家-->架构师
领域并不是纯业务
领域，子域，核心域，通用域，支撑域
领域：指特定的范围（边界）或区域→细分→领域模型→代码实现
领域→划分→子领域→更小的问题域\更小的业务范围
子域根据自身的重要性和功能属性划分为三类：核心域（决定产品和公司核心竞争力的子域）、通用域（同时被其他多个子域通用功能的子域）、支撑域（功能子域、不包含决定产品核心竞争力的功能，不包含通用功能的子域）
通用域：通用系统，认证，权限，日志，不存在太多特性，和业务无关，服务整个业务领域，日志子域
支撑域：具有企业特性，不具有通用性
领域的核心思想，问题逐级划分，降级业务理解和系统的实现复杂度
核心域是业务系统的核心价值所在，系统中的重中之重
通用域：为整个业务系统提供通用服务，其他子域都是消费者
支撑域专注于业务系统的某一重要业务，来支撑和完善业务系统
限界上下文：
（定义上下文的含义）通用语言和（定义领域边界）限界上下文两个重要概念 （战略设计）
通过团队交流达成共识，能够简单、清晰、准确描述业务含义和规则语言
DDD核心概念
实体和值对象 领域模型中的领域对象
实体类的设计，直接反应数据库表结构
传统：关注数据
DDD实体是唯一的并且可以持续变化的
业务中：实体是多个属性、操作和行为的载体
代码：实体类，包含属性和方法，充血模型
运行形态：领域对象：唯一的ID
数据库：领域模型映射到数据模型，一个实体可能对应0个、1个或多个数据持久化对象
值对象：本质集合，描述实体的属性
值对象：值和对象，值的特点是固定不变。用对象的方式来表述某个值
业务对象：物理上独立出来，逻辑上仍然和实体是一体的
值对象，单一的属性，实体类的属性
值对象创建以后不允许修改
值对象：一把双刃剑。。。简化数据库设计，性能就提供
无法满足快速查询
值对象无法单独存在，单独存在的值对象没有任何意义，，他只是实体一部分的特征是属性
实体和值对象（个体化的对象）
值对象依附于实体的，实体属性的一部分
实体核心是唯一性，延续性
值对象核心是描述
聚合与聚合根
聚合，一种强关联关系，整体与部分
聚合：相关联的领域对象进行显式的分组，表达整体的概念
聚合（数据仓储）：业务和逻辑紧密关联的实体和值对象组合而成
聚合：聚合根和上下文边界
DDD分层架构：聚合在领域层，包含； 多个聚合
领域服务和应用服务
领域服务：表述领域行为，对应行为的细化，具体谋一环节
应用服务：表述应用行为，具体操作，从开始到结束的每一环节
聚合根主要目的，为了避免由于复杂数据模型缺少统一的业务规则控制，导致聚合和实体之间，数据不一致的问题
聚合根（全局唯一标识，其他的状态信息都是可变的），实体（聚合内部才有唯一的本地标识），值对象（没有标识，只读）
聚合根：本质就是实体
DDD:是一个用来设计系统架构的思想，本身不是架构
DDD分层架构
严格分层架构 、松散分层架构
优点：程序结构清晰
分层架构的优点：开发人员可以只关注整个结构中的某一层
替换原有层次的实现
降低层与层之间的依赖
领域模型存在于限界上下文中
DDD的设计思想，去指导我们如何进行架构，利用分层
微服务的架构中，边界非常重要
仓储服务：接口和实现
洋葱架构：整洁架构，在项目中只有三层（核心应用，用户界面，基础设施
六边形架构：端口适配器架构
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
