领域驱动设计DDD

领域驱动设计

领域驱动设计过程

战略设计

问题域方面

限界上下文（Bounded Context）

上下文映射（Context Map）

核心领域（Core Domain）

子领域（SubDomain）

架构方面

分层架构

六边形架构

CQRS 模式

战术设计

战术设计诸要素设计

值对象（Value Object）

实体（Entity）

领域服务（Domain Service）

领域事件（Domain Event）

资源库（Repository）

工厂（Factory）

聚合（Aggregate）

应用服务（Application Service）

数据库架构

数据库共享架构

零共享架构

限界上下文、六边形与微服务之间就成了“三位一体”

分层的依据

基于关注点为不同的调用目的划分层次

面对变化

限定上下文

领域逻辑层面：限界上下文确定了领域模型的业务边界，维护了模型的完整性与一致性，从而降低系统的业务复杂度。

团队合作层面：限界上下文确定了开发团队的工作边界，建立了团队之间的合作模式，避免团队之间的沟通变得混乱，从而降低系统的管理复杂度。

技术实现层面：限界上下文确定了系统架构的应用边界，保证了系统层和上下文领域层各自的一致性，建立了上下文之间的集成方式，从而降低系统的技术复杂度。

引入限界上下文的目的，其实不在于如何划分边界，而在于如何控制边界。

分而治之

开放封闭原则（OCP）

统一语言

统一的领域术语

领域行为描述

领域场景分析

6W模型

用户故事

这是错误的

我们在编写用户故事时，应该按照行为驱动开发的要求，关注于做什么（what），而不是怎么做（how）

在业务建模阶段，业务才是重心，不能舍本逐末。

从 UI 操作去表现业务行为

描述技术实现而非业务需求

复杂度

应对措施

隔离业务复杂度与技术复杂度

分层架构的关注点分离

限界上下文的分而治之

技术复杂度：来自需求的质量属性

业务复杂度：对应了客户的业务需求