000001_DDD领域建模知识分享
领域驱动架构设计详细讲解（一）
领域驱动架构设计详细讲解（⼀）⼀、什么是DDD？DDD⼜叫领域驱动设计，它是⼀种软件开发的思想，不是具体的技术或者框架，它的核⼼是维护⼀个能够反映领域概念的模型，通过⼀些模式和约束来指导团队进⾏统⼀的设计开发。
⼆、为什么要使⽤DDD？从技术层⾯进⾏分层，每层都在关注⾃⼰的事情，⽐如领域层关注业务逻辑，仓储层关注持久化数据，应⽤服务层关注协调领域层和仓储层实现某⼀个业务，接⼝层关注暴露应⽤服务接⼝给外界调⽤从业务维度，将⼤的系统划分为多个领域界限，可以选择将不同的界限分配给不同的团队、不同的界限使⽤不同的仓储，实现界限内是⾼内聚⽽界限之间是低耦合的由于DDD只是⼀种开发理念，所以要想在项⽬中发挥他的作⽤，我们需要先搞懂它⾥⾯的⼀些基本概念和核⼼组件，然后基于它搭建⼀个轻量级的框架。
三、DDD的核⼼组件1.领域界限：对于⼀个系统⽽⾔，我们对其按照不同的领域划分不同的界限，不同的领域界限之间可以是相互独⽴的。
每个领域内都有⾃⼰独⽴的领域逻辑、数据持久化和接⼝等。
2.聚合的概念：通常我们会将多个实体和值对象进⾏组合来表达⼀个完整的概念，⽐如订单实体、订单详情实体、订单收货信息组成了⼀个完整的订单概念，他们的⽣命周期是⼀样的，在进⾏持久化时也应该进⾏统⼀持久化。
3.聚合根的概念：对于⼀个聚合⽽⾔，必须有⼀个对象能够表达这个聚合的总概念，外界想要对这个聚合进⾏持久化的操作时，必须通过这个总概念进⾏协调，通过它来保证业务⼀致性，那么这个对象我们就称之为聚合根。
在⼀个聚合中有且只有⼀个聚合根，想要访问聚合内的对象，必须要通过聚合根才能进⾏访问（当然，其他的实体可以在外界需要查询时临时调⽤），聚合根拥有唯⼀的标识，也拥有业务⽣命周期，其本质也是实体。
⽐如订单聚合中的订单实体即为这个聚合的聚合根。
4.实体的概念：实体是⼀个有业务⽣命周期的概念，拥有唯⼀标识⽤于标识和区分。
⽐如⼀个订单对象就是⼀个实体。
5.值对象的概念：值对象是⼀个⽆业务⽣命周期的概念，通常⽤于定义聚合中的某⼀个复杂的对象属性，不需要定义标识进⾏区分。
《领域驱动设计》基础知识汇总
《领域驱动设计》基础知识汇总《领域驱动设计》（Domain-Driven Design，简称DDD）是一种软件开发方法论，它将软件开发过程中的关注点从技术细节转移到业务领域上。
DDD强调将业务需求和软件模型紧密对应，以便更好地理解业务需求，并将其准确地转化为可执行的软件模型。
以下是《领域驱动设计》的基础知识汇总。
1.领域驱动设计的核心思想是通过将知识转化为模型来解决复杂问题。
领域模型是对业务领域知识的抽象和表达，它将业务对象、业务规则和业务流程等概念化地表示出来。
2.领域驱动设计强调领域专家参与，并与开发团队紧密合作。
领域专家是对业务领域非常熟悉的人，他们能够提供与业务相关的知识和经验，并对软件开发过程中的需求和模型进行指导。
3.领域驱动设计提倡使用统一的语言来描述业务领域。
该语言应该由领域专家和开发团队共同创造，以最大程度地减少沟通障碍并提高开发效率。
4.领域驱动设计中的聚合是一个非常重要的概念。
聚合是一个具有内聚性的对象集合，它们被视为一个整体并按照一定的规则进行操作和管理。
聚合根是聚合中最核心的对象，它负责管理整个聚合的状态和行为。
5.领域驱动设计中的领域事件是一种重要的机制，用于解耦和通信。
领域事件是业务领域中发生的一些关键事件，它们被抽象为领域事件，并且可以被其他对象订阅和处理。
6.领域驱动设计中的领域服务是一种封装了业务逻辑的对象，它不属于任何聚合和实体，负责处理那些跨聚合的复杂业务逻辑。
领域服务可以与其他对象进行协作，但它不应该持有状态。
7.领域驱动设计中的领域模型需要经过持久化以便在不同的系统之间共享和使用。
领域模型可以通过使用ORM框架或其他数据持久化技术来实现，并根据需要进行优化。
8.领域驱动设计强调使用领域驱动设计模式来解决常见的设计问题。
这些模式包括实体、值对象、仓储、工厂、规范等，它们提供了一些通用的解决方案，可以帮助开发人员更好地组织和管理领域模型。
9.领域驱动设计需要采用迭代增量的方式进行开发，将复杂的需求拆分成小的任务，并通过测试驱动开发的方式逐步实现。
领域驱动设计（DDD）的实践经验分享之ORM的思考
领域驱动设计（DDD）的实践经验分享之ORM的思考最近⼀直对DDD(Domain Driven Design)很感兴趣，于是去⽹上找了⼀些⽂章来看看，发现它确实是个好东西。
于是我去买了两本关于领域驱动设计的书本和⼀本企业应⽤架构模式的书。
看了之后也掌握了⼀些理论基础。
但总感觉需要通过做⼀个实际项⽬来测试⾃⼰所学到的知识。
因为以前我开发过⼀个叫做“蜘蛛侠论坛”的⽹站，官⽅演⽰地址：（论坛⽬前已关闭，需要源代码的可以联系我），但在我学习了DDD之后，才明⽩原来之前我所做的设计是贫⾎模型+事务脚本的设计⽅法。
这种设计⽅法有很多不⾜，最⼤的不⾜就是业务逻辑不能重⽤，业务逻辑没有组织为⼀个可重⽤的⾃封闭的业务模型。
所以我想⽤DDD的思想来重新设计我的论坛。
⼤家都知道，⼀般我们在做DDD架构的应⽤时，⼀般会分成四层：1. Presentation Layer：展现层，负责显⽰和接受输⼊；2. Application Layer：应⽤层，很薄的⼀层，只包含⼯作流控制逻辑，不包含业务逻辑；3. Domain Layer：领域层，包含整个应⽤的所有业务逻辑；4. Infrastructure Layer：基础层，提供整个应⽤的基础服务；⼀开始接触这样的架构时，觉得确实很好。
但后来在不断实践中遇到了不少问题，下⾯⼏个就是我所遇到的⼏个关键问题，在接下来的随笔中我将会⼀⼀和⼤家分享我是如何思考和解决这些问题的。
1. 是否应该使⽤ORM；2. 持久化透明；3. ⾼性能；4. 事务⽀持；是否应该使⽤ORM？⼤家都知道ORM能将对象和数据库进⾏映射，它可以让开发⼈员完全按照⾯向对象的思维去设计实现软件，并且你⽆需关⼼对象如何从数据库取出来或保存到数据库。
但是我发现⼏乎我所见过的所有ORM框架都基于同⼀个前提，那就是将对象的属性映射到数据库字段，将对象之间的引⽤映射到数据库表的关系。
然后如果当你需要⼀些⾼级功能⽀持时，ORM会要求你对你的对象做⼀些设置，⽐如在NHibernate中，你如果要进⾏Lazy Load，你就必须将属性设置为virtual，如果是⼀对多，好像还有个叫ISet的东东吧，我不是太了解。
ddd领域模型设计使用场景
ddd领域模型设计使用场景摘要：1.领域模型设计的概念和重要性2.ddd 领域模型设计的基本原则3.ddd 领域模型设计的使用场景4.ddd 领域模型设计的实际应用案例5.总结正文：1.领域模型设计的概念和重要性领域模型设计是软件开发中的一个重要环节，它是对业务领域的建模和抽象。
在软件开发过程中，领域模型设计能够有效地帮助开发者理解和把握业务需求，从而实现高质量的软件开发。
ddd（Domain-Driven Design，领域驱动设计）是一种软件开发方法论，其核心思想是将复杂的业务领域进行抽象，并通过领域模型设计来实现对业务的深入理解和把握。
2.ddd 领域模型设计的基本原则在ddd 领域模型设计中，有几个基本的原则需要遵循：- 核心领域模型原则：领域模型设计应该抓住业务的核心，对核心概念进行建模和抽象。
- 丰富模型原则：在领域模型设计中，应该尽可能地对业务场景进行丰富建模，以便在实际应用中能够灵活应对各种业务需求。
- 模型映射原则：领域模型设计应该与数据库表结构进行映射，以便在实际开发中能够方便地进行数据操作。
3.ddd 领域模型设计的使用场景ddd 领域模型设计在实际应用中有广泛的使用场景，主要包括以下几个方面：- 复杂业务系统的开发：在开发复杂的业务系统时，领域模型设计能够有效地帮助开发者理解和把握业务需求，从而实现高质量的软件开发。
- 业务领域变化频繁的场景：在业务领域变化频繁的情况下，领域模型设计能够方便地进行模型的调整和优化，以适应不断变化的业务需求。
- 大型项目的开发：在大型项目的开发过程中，领域模型设计能够有效地对业务领域进行拆分和抽象，从而实现模块化和组件化的开发。
4.ddd 领域模型设计的实际应用案例在实际应用中，ddd 领域模型设计已经被广泛应用，并取得了良好的效果。
比如，在电商系统的开发中，通过领域模型设计，开发者能够深入理解电商业务的核心概念，如订单、商品、库存等，从而实现高质量的电商系统开发。
ddd领域建模的核心方法
ddd领域建模的核心方法
领域驱动设计（DDD）是一种用于软件开发的方法论，其目的在于将软件系统与其所处的业务领域紧密结合起来，从而更好地满足业务需求。
在DDD中，领域建模是一项关键的工作，其目的在于将业务领域中的概念、行为和关系转化为程序代码。
DDD领域建模的核心方法主要包括以下几个方面：
1. 划分领域模型：将业务领域中的实体、值对象、聚合和领域服务等划分为不同的领域模型，以便更好地管理和维护。
2. 设计实体和值对象：实体和值对象是DDD领域模型中最基本的构建块，其设计应该尽可能地反映业务领域中的实际情况。
3. 定义聚合：聚合是一组实体和值对象的集合，其具有较高的内聚性和松散的耦合性。
在DDD中，聚合被视为一个整体，具有唯一标识符和一系列约束条件。
4. 建立领域服务：领域服务是实现业务逻辑的重要构建块，其目的在于将特定的业务规则封装在一个可重用的组件中，以便在不同的应用场景中复用。
5. 应用CQRS架构：CQRS（Command and Query Responsibility Segregation）是DDD中的一种架构模式，其主要思想在于将写操作和读操作分离开来，以提高系统的可扩展性和性能。
综上所述，DDD领域建模的核心方法涵盖了领域模型划分、实体和值对象设计、聚合定义、领域服务建立以及CQRS架构应用等方面，其目的在于将业务领域中的概念与程序代码紧密结合起来，以便更好
地满足业务需求。
领域驱动设计(DDD)部分核心概念的个人理解
领域驱动设计（DDD）部分核心概念的个人理解领域驱动设计（Domain Driven Design，DDD）是一种软件开发方法论，旨在建立一个由领域专家和技术人员共同合作的模型，以解决复杂业务问题。
DDD强调将关注点从技术转移到领域本身，使得软件开发更加专注于业务的核心需求。
在DDD中，有一些核心概念是理解该方法论的基础。
以下是我个人对DDD核心概念的理解：1. 领域（Domain）：领域是业务问题所涉及的特定领域或业务场景。
它定义了问题的边界和范围。
在DDD中，我们将软件开发的焦点从技术转移到了领域本身。
2. 领域模型（Domain Model）：领域模型是对领域知识的概念化表达。
它是一个数据模型和业务逻辑之间的集合。
领域模型通过实体、值对象、聚合和领域服务等概念来描述业务问题的结构和行为。
3. 实体（Entity）：实体是领域模型中的一个核心概念。
它代表一个有唯一标识的具体对象，该对象具有自己的属性和行为。
通过标识，实体可以被唯一地区分并进行持久化。
4. 值对象（Value Object）：值对象是领域模型中的另一个重要概念。
它代表没有唯一标识的对象，通常是由多个属性组成的不可变对象。
值对象的相等性通常是基于属性而不是标识。
5. 聚合（Aggregate）：聚合是一组相关对象的集合，可以作为一个整体进行操作和管理。
聚合有一个聚合根（Aggregate Root），通过聚合根可以访问和管理聚合中的其他对象。
聚合定义了业务规则和一致性边界。
6. 领域服务（Domain Service）：领域服务是一个封装了领域行为的实现。
它通常在多个实体和值对象之间进行操作，执行一些复杂的业务逻辑。
领域服务可以被视为领域模型中的一层抽象和组织。
7. 限界上下文（Bounded Context）：限界上下文是分解大型领域模型为更小、更可管理的部分的一种方法。
每个限界上下文都有自己的领域模型，用于解决特定的业务子领域。
软件架构中的领域驱动设计(DDD)
软件架构中的领域驱动设计(DDD)领域驱动设计(DDD)是一种软件开发方法论，它将软件项目的设计和实现过程，建立在对业务领域的深入理解基础之上。
通过将业务领域的知识和经验融入到软件设计和开发的过程中，DDD可以帮助开发团队更好地理解业务需求，提高软件的质量和稳定性。
1. DDD的基本概念领域驱动设计的核心思想是将软件系统划分为不同的领域，每个领域都有自己的业务模型、规则和流程。
通过深入了解这些领域的特点和要求，开发团队可以设计出更加贴合实际需求的软件架构和系统设计。
在领域驱动设计中，通常会使用领域模型、领域事件和领域服务等概念，来帮助团队更好地理解和实现业务需求。
2. DDD的核心概念2.1领域模型领域模型是领域驱动设计的核心概念，它是对领域中各种实体、值对象、聚合和领域服务等概念的抽象和建模。
通过领域模型的建立，开发团队可以更好地理解业务逻辑和规则，从而设计出更加贴合实际需求的软件系统。
领域模型通常是通过领域专家和开发团队的合作来构建的，它是对业务需求的一种抽象和概括。
2.2领域事件领域事件是领域驱动设计中的另一个核心概念，它是描述领域中事件发生和影响的概念。
通过将领域中的各种事件进行抽象和建模，开发团队可以更好地理解各种业务规则和流程，从而设计出更加稳定和可靠的软件系统。
领域事件通常是领域模型的一部分，它描述了业务领域中的各种重要事件和影响。
2.3领域服务领域服务是领域驱动设计中的另一个重要概念，它是对业务领域中某些重要操作和逻辑的抽象和建模。
通过领域服务，开发团队可以更好地处理各种业务逻辑和操作，从而设计出更加灵活和可扩展的软件系统。
领域服务通常是领域模型的一部分，它描述了业务领域中的各种重要操作和逻辑。
3. DDD的应用实践在日常的软件开发过程中，领域驱动设计可以帮助开发团队更好地理解和实现业务需求，提高软件系统的质量和稳定性。
在应用领域驱动设计的实践中，通常会涉及到以下几个方面的工作：3.1领域分析和建模领域分析和建模是领域驱动设计的重要环节，它通过与业务专家的沟通和合作，来深入了解业务领域的特点和要求，从而建立起相应的领域模型、领域事件和领域服务等概念。
领域模型驱动设计（DDD）之模型提炼
当Java世界提供的可选择性框架平台越来越多时，我们可能被平台架构所深深困扰，⽽⽆暇顾及软件的真正核⼼：业务建模，其实，业务领域建模同样是⼀个⽐平台架构更复杂，更需要学习的新的领域。
相反，在实践中，我们技术⼈员在经过冗长的平台架构学习和实践后，就匆忙开始项⽬开发，这时是什么指导他们进⾏软件业务实现呢？⼤部分可能是依赖数据库建模，甚⾄是复杂冗长的数据库存储过程设计，这些已经开始⾛向⾯向对象分析设计的反⽅向，⾛上了⼀条错误的软件开发⽅向，最终开发出缓慢的、经常当机的Java企业系统。
如果你没有恰当的OO设计思想，Java就会⽤性能惩罚你，这可能是Java世界的⼀个潜规则。
那么，⼀个正确的OOA/OOD/OOP步骤是什么呢？⽬前围绕模型驱动设计(MDD)的设计思想成为主流思想，MDA更是在MDD基础上提升和升华。
下⾯让我们⾸先了解，如何使⽤领域驱动设计思想来分析设计⼀个软件系统。
当我们不再对⼀个新系统进⾏数据库提炼时，取⽽代之的时⾯向对象的模型提炼。
我们必须⼤⼑阔斧地对业务领域进⾏细分，将⼀个复杂的业务领域划分为多个⼩的⼦领域，同时还必须分清重点和次要部分，抓住核⼼领域概念，实现重点突破。
核⼼领域模型 精简模型，找出核⼼领域，将业务需求中最有价值的概念体现出来，让核⼼变精要，这实际就是⼀个使复杂问题变简单的过程，也是对我们软件设计⼈员真正能⼒的考验。
核⼼领域模型不是轻易能够发现，特别是他处于⼀个纷乱复杂的众多领域模型结构中时，核⼼模型通常是我们某个⼦领域关注的重点，例如订单模型是订单管理领域的核⼼；消息模型是论坛或消息领域系统的核⼼。
⽬前，分析领域有很多模式来帮助我们来提炼核⼼模型，例如四⾊原型、Martin Fowler 的分析模式等，例如MF的"分析模式"(Analysis Patterns)中的记帐模型就是不仅仅⽤来记录账⽬数值，⽽且可以记录和控制账⽬的每⼀次修改。
DDD领域驱动设计基本理论知识总结
▪领域驱动设计之领域模型▪为什么建立一个领域模型是重要的▪领域通用语言（UBIQUITOUS LANGUAGE）▪将领域模型转换为代码实现的最佳实践▪领域建模时思考问题的角度▪领域驱动设计的经典分层架构▪用户界面/展现层▪应用层▪领域层▪基础设施层▪领域驱动设计过程中使用的模式▪所有模式的总揽图▪关联的设计▪实体（Entity）▪值对象（Value Object）▪领域服务（Domain Service）▪应用层服务▪领域层服务▪基础层服务▪聚合及聚合根（Aggregate，Aggregate Root）▪聚合有以下一些特点：▪如何识别聚合？▪如何识别聚合根？▪工厂（Factory）▪仓储（Repository）▪设计领域模型的一般步骤▪在分层架构中其他层如何与领域层交互▪对于会影响领域层中领域对象状态的应用层功能▪关于Unit of Work（工作单元）的几种实现方法▪对于不会影响领域层中领域对象状态的查询功能▪为什么面向对象比面向过程更能适应业务变化▪领域驱动设计的其他一些主题▪一些相关的扩展阅读▪CQRS架构▪Event Sourcing（事件溯源）▪DCI架构▪四色原型分析模式▪时刻-时间段原型（Moment-Interval Archetype）▪参与方-地点-物品原型（Part-Place-Thing Archetype）▪描述原型（Description Archetype）▪角色原型（Role Archetype）领域驱动设计之领域模型加一个导航，关于如何设计聚合的详细思考，见这篇文章。
2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计），简称Evans DDD。
领域驱动设计分为两个阶段：以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；由领域模型驱动软件设计，用代码来实现该领域模型；由此可见，领域驱动设计的核心是建立正确的领域模型。
ddd领域模型设计 c语言
ddd领域模型设计 c语言C语言是一种通用的高级编程语言，广泛应用于各个领域。
其中，DDD（领域驱动设计）是一种软件开发方法论，旨在解决复杂业务场景下的软件设计与开发问题。
本文将探讨如何在C语言中应用DDD进行领域模型设计。
领域模型是DDD中的核心概念，它是对业务领域的抽象和建模。
在C语言中，我们可以通过定义结构体和函数来实现领域模型的设计。
下面以一个简单的图书管理系统为例，介绍如何在C语言中进行领域模型设计。
我们需要定义图书的实体模型。
在C语言中，可以使用结构体来表示图书的属性。
例如，我们可以定义一个Book结构体，包含图书的名称、作者和出版日期等信息。
```ctypedef struct {char title[100];char author[50];char publishDate[20];} Book;```接下来，我们可以定义一些操作图书的函数，例如添加图书、删除图书和查询图书等。
这些函数将直接操作图书实体，并通过参数和返回值来传递数据。
```cvoid addBook(Book* book) {// 添加图书的具体逻辑}void deleteBook(Book* book) {// 删除图书的具体逻辑}Book* findBook(char* title) {// 查询图书的具体逻辑，并返回匹配的图书}```在DDD中，领域模型还包括领域服务和领域事件等概念。
在C语言中，我们可以使用函数指针来实现领域服务和回调函数来实现领域事件。
例如，我们可以定义一个BookService结构体，包含一些操作图书的服务方法。
这些服务方法将作为函数指针传递给其他模块，实现模块间的解耦和扩展。
```ctypedef struct {void (*addBook)(Book* book);void (*deleteBook)(Book* book);Book* (*findBook)(char* title);} BookService;```我们还可以定义一些领域事件，例如图书借阅事件和归还事件。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Agenda
01
什么是DDD？
05
基于微服务架构 构建旅程
02
为什么要使用 DDD？
06
DDD设计原则
03
DDD核心概念
04
DDD需求分析、 设计、开发流程
07
DDD常用架构模式
08
根 • 聚合的特点：高内聚、低耦合，它是领域模型中最底层的边界，可以作为拆分微服务的最小单位，但我不建议你
对微服务过度拆分。但在对性能有极致要求的场景中，聚合可以独立作为一个微服务，以满足版本的高频发布和 极致的弹性伸缩能力。一个微服务可以包含多个聚合，聚合之间的边界是微服务内天然的逻辑边界。有了这个逻 辑边界，在微服务架构演进时就可以以聚合为单位进行拆分和组合了，微服务的架构演进也就不再是一件难事了。 • 聚合根的特点：聚合根是实体，有实体的特点，具有全局唯一标识，有独立的生命周期。一个聚合只有一个聚合 根，聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织和协调，聚合根与聚合根之间通过 ID 关联 的方式实现聚合之间的协同。
聚合中的不变性
• 不变性定义：无论何时数据发生变化，都必须满足所有一致变化的规则 ,俗话：同生死。 • 聚合内部的不变量必须在每次事务完成时满足。可以用仓储来实现。 • 一些依赖关系只能在某些特定的时刻通过事件借助有事务支持的服务来完成，或通过线程
安全模式实现原子操作。
实体
• 实体就是领域中需要唯一标识的领域概念。因为实体有生命周期，实体从被创建后可能会 被持久化到数据库，然后某个时候又会被取出来。
DDD 领域建模知识分享
Agenda
01
什么是DDD？
05
基于微服务架构 构建旅程
02
为什么要使用 DDD？
06
DDD设计原则
03
DDD核心概念
04
DDD需求分析、 设计、开发流程
07
DDD常用架构模式
08
简单代码案例讲 解
Agenda
01
什么是DDD？
05
基于微服务架构 Βιβλιοθήκη 建旅程02为什么要使用 DDD？
问题分析
业务到产品，只是分析，无设计的反馈 产品人员的设计没有技术实现作为实时反馈，导致错误百出 设计错误，加上沟通错误在下阶段的实现中被放大 设计的知识遗失
传统模式：
业务
产品
开发
解决方案 - DDD
业务、产品、开发一起 业务：领域专家，提供领域知识和验证软件实现 产品：协调沟通；提供功能、非功能需求；开发领域测试案例；UI设计 开发：与业务和产品一起开发统一语言，设计并实现领域模型
限界上下文，领域和子域
限界上下文 • 是业务和语义的边界 领域 • 是问题域 核心域 • 企业的核心竞争力，需自建 支持域 • 具有企业特性，例如数据字典，可外包开发 通用域 • 没有企业特性的功能，可外购产品来构建能力
聚合
• 一个聚合包含一个或多个实体/值对象 • 一个聚合定义了一个数据一致性边界，例如：聚合内所以的实体保持事务的一致性 • 每个聚合都有一个聚合根和一个边界。 • 边界定义了聚合中应该包含什么。 • 每个聚合都有一个根实体，这个根实体做聚合根 • 聚合根是聚合中唯一允许被外部引用的元素，在聚合边界内，对象之间可以相互引用。 • 举个简单的例子，一个电脑包含硬盘、CPU、内存条等，这一个组合就是一个聚合，而电脑就是这个组合的聚合
DDD核心概念
04
DDD需求分析、 设计、开发流程
07
DDD常用架构模式
08
简单代码案例讲 解
领域驱动全景图
统一语言
统一语言是一个问题域里，所有相关人员所使用， 并且理解（不用再解释）的共同语言 • 产品、业务、开发、测试共用 • 每个问题域或限界上下文都有各自的通用语言。
同样的术语在各个领域里意义不一样
新的开发模式
影响 UI
需求文档 PO（产品）
领域测试案例
领域专家（业务）
提供领域知识 验证模型结果
测试
Ubiquitous Language
领域模型 （代码）
实现领域 测试案例 （自动化）
开发
Agenda
01
什么是DDD？
05
基于微服务架构 构建旅程
02
为什么要使用 DDD？
06
DDD设计原则
03
• 实体的特点：有 ID 标识，通过 ID 判断相等性，ID 在聚合内唯一即可。状态可变，它依附于 聚合根，其生命周期由聚合根管理。实体一般会持久化，但与数据库持久化对象不一定是 一对一的关系。实体可以引用聚合内的聚合根、实体和值对象。
• 实体管理自己的属性和行为，并暴露行为
值对象
• 值对象的特点：无 ID，不可变，无生命周期，用完即扔。值对象之间通过属性值判断相等 性。它的核心本质是值，是一组概念完整的属性组成的集合，用于描述实体的状态和特征。 值对象尽量只引用值对象。
• 比如一个用户的Address为例，如果两个用户的地址是一样的。也就是说只要地址信息一样， 我们就认为是同一个地址。
简单代码案例讲 解
Why DDD – 问题
开发：产品花太多时间调研，给我们太少时间开发 业务：怎么加这么小一个功能都要这么长时间 产品：你知道这个产品逻辑有多复杂？又是第一次，没人做过 测试：系统太复杂，来不及仔细测试 用户：这个产品稳定性怎么这么差 新来的开发：怎么文档都没有，我需要n周时间熟悉系统 领导：我只看结果，别给我找借口 老婆：你再996，我就离婚
领域建模是一种艺术的技术，它是用来解决复杂软件快速应付变化的解决之道
DDD是一种设计思想，它是基于事件风暴，使用通用语言，对业务进行领域建模，通过限界上下文对业务进行合理的领域拆
分，使得领域模型更好地转向微服务和落地，从而解决复杂系统难以理解，难以演进，也可以解决服务业务界限难以界定的问题。
战略设计 • 建立领域模型，划分服务边界，建立通用的限界上下文 战术设计 • 侧重于领域模型的实现，从领域模型转向微服务的设计和落地
06
DDD设计原则
03
DDD核心概念
04
DDD需求分析、 设计、开发流程
07
DDD常用架构模式
08
简单代码案例讲 解
Evans DDD
2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计 ）简称Evans DDD