领域驱动建模(EvansDDD)
ddd发展历史
ddd发展历史一、背景介绍DDD（Domain-Driven Design，领域驱动设计）是一种软件开发方法论，它的核心理念是将软件系统的设计与业务领域的概念模型相结合，以提高软件系统的质量和可维护性。
DDD的发展历史可以追溯到上世纪90年代，当时软件开发领域中出现了一些困扰开发者的问题：软件系统难以理解、难以维护、与业务需求脱节等。
为了解决这些问题，一些先驱者开始尝试将领域概念引入软件开发中，从而催生了DDD的发展。
二、DDD的起源DDD的起源可以追溯到1996年，当时埃里克·埃文斯（Eric Evans）在他的著作《领域驱动设计：软件核心复杂性应对之道》中首次提出了DDD的概念。
他认为软件系统的核心复杂性来自于业务领域本身，而不是技术实现。
因此，应该将业务领域的概念模型作为软件系统设计的核心，以便更好地理解和解决业务问题。
三、DDD的发展过程1. 概念的完善在提出DDD的概念后，埃里克·埃文斯不断完善和丰富了DDD的理论框架。
他提出了一系列与DDD相关的概念和方法，如聚合、实体、值对象、领域服务等。
这些概念和方法帮助开发者更好地理解和建模业务领域，使软件系统更贴近实际业务需求。
2. 实践的推广随着DDD理论的逐渐完善，越来越多的开发者开始尝试将DDD应用于实际项目中。
他们发现，DDD能够帮助他们更好地理解业务需求，减少开发过程中的沟通成本，并提高软件系统的质量和可维护性。
因此，DDD逐渐得到了广泛的推广和应用。
3. 工具和框架的支持为了更好地支持DDD的实践，一些工具和框架相继出现。
例如，Martin Fowler提出的“领域特定语言”（Domain-Specific Language，DSL）可以帮助开发者更好地表达和实现业务规则。
另外，一些开源框架如Spring Framework、Entity Framework等也提供了对DDD的支持，使开发者能够更方便地应用DDD。
理解软件开发中的领域驱动设计
理解软件开发中的领域驱动设计在当今的信息时代中，软件应用已经无处不在，无论是在日常生活中，还是在企业管理和发展中，都扮演着重要的角色。
然而，随着软件的不断发展，其应用也变得越来越复杂，需要更多的专业知识和技能来满足市场的需求。
领域驱动设计（Domain-Driven Design，DDD）是一种面向对象的软件开发方法，旨在帮助开发人员更好地理解复杂的业务领域，从而更好地设计和构建软件应用。
本文将介绍领域驱动设计的基本概念、技术原则和实际应用方法，帮助读者更好地理解软件开发中的领域驱动设计。
一、领域驱动设计的基本概念领域驱动设计（Domain-Driven Design，DDD）是由Eric Evans在2003年提出的一种面向对象的软件开发方法，它通过对业务领域的深入理解，设计和构建能够满足复杂业务需求的软件应用。
领域是指一组相关的业务活动，这些业务活动共同构成了一个完整的业务过程。
例如，在物流行业中，物流领域包括运输、仓储、送货等业务活动，它们相互关联，最终构成了一个完整的货物运输过程。
软件应用通常是在一个特定的业务领域内开发的，因此，领域驱动设计的核心思想是将软件应用的设计和实现与业务领域紧密结合起来，以实现更好地业务需求和更好的软件结构。
领域模型是领域驱动设计的核心概念之一。
它用于描述业务领域中对象之间的关系和过程，包含了实体、值对象、聚合根、仓储、服务等元素。
实体是指具有唯一标识、状态和行为的业务对象，它是整个领域模型中最重要的部分。
例如，在物流行业中，货物、订单等都可以是实体。
值对象是指没有唯一标识、不可变的业务对象，例如，货物的规格、订单的收货地址等。
聚合根是指在业务领域中最重要的实体，所有的业务操作都是从聚合根开始的。
仓储是指将实体对象进行持久化的技术手段，服务是指执行业务过程的方法。
二、领域驱动设计的技术原则领域驱动设计包含了一些重要的技术原则，用于指导软件开发人员进行软件设计和开发。
领域驱动设计(DDD)架构的实践
领域驱动设计（DDD）架构的实践前言至少30年以前，一些软件设计人员就已经意识到领域建模和设计的重要性，并形成一种思潮，Eric Evans将其定义为领域驱动设计（Domain-Driven Design，简称DDD）。
在互联网开发“小步快跑，迭代试错”的大环境下，DDD似乎是一种比较“古老而缓慢”的思想。
然而，由于互联网公司也逐渐深入实体经济，业务日益复杂，我们在开发中也越来越多地遇到传统行业软件开发中所面临的问题。
本文就先来讲一下这些问题，然后再尝试在实践中用DDD的思想来解决这些问题。
问题过度耦合业务初期，我们的功能大都非常简单，普通的CRUD就能满足，此时系统是清晰的。
随着迭代的不断演化，业务逻辑变得越来越复杂，我们的系统也越来越冗杂。
模块彼此关联，谁都很难说清模块的具体功能意图是啥。
修改一个功能时，往往光回溯该功能需要的修改点就需要很长时间，更别提修改带来的不可预知的影响面。
下图是一个常见的系统耦合病例。
订单服务接口中提供了查询、创建订单相关的接口，也提供了订单评价、支付、保险的接口。
同时我们的表也是一个订单大表，包含了非常多字段。
在我们维护代码时，牵一发而动全身，很可能只是想改下评价相关的功能，却影响到了创单核心路径。
虽然我们可以通过测试保证功能完备性，但当我们在订单领域有大量需求同时并行开发时，改动重叠、恶性循环、疲于奔命修改各种问题。
上述问题，归根到底在于系统架构不清晰，划分出来的模块内聚度低、高耦合。
有一种解决方案，按照演进式设计的理论，让系统的设计随着系统实现的增长而增长。
我们不需要作提前设计，就让系统伴随业务成长而演进。
这当然是可行的，敏捷实践中的重构、测试驱动设计及持续集成可以对付各种混乱问题。
重构——保持行为不变的代码改善清除了不协调的局部设计，测试驱动设计确保对系统的更改不会导致系统丢失或破坏现有功能，持续集成则为团队提供了同一代码库。
在这三种实践中，重构是克服演进式设计中大杂烩问题的主力，通过在单独的类及方法级别上做一系列小步重构来完成。
实战DDD（Domain-DrivenDesign领域驱动设计：EvansDDD）[...
实战DDD（Domain-DrivenDesign领域驱动设计：EvansDDD）[...面向对象与领域建模板桥里人 2006/12/6（转载请保留）如果没有多变的需求，也许就没有今天的面向对象软件，我们曾经试图通过需求管理、需求跟踪等等管理方式约束和减少需求频繁更新带给软件的冲击，可是这样下去的结果只有一个：使得软件更加僵化；或者程序员更加劳累。
需求不但多变，而且经常是不可能第一次就能掌握，需求反映了某个领域的专业知识，例如数学、管理、财务或电子商务等等，每个特定案例需求又有其特别复杂之处，几乎没有人能够第一次接触就可以深入掌握这些专业领域的需求本质，就是专门的建模专家也不例外。
既然需求是多变而且复杂的，所以，就不能使用“堵”式方法对其进行控制和管理，只能顺势而为，通过灵活多变的以及迭代反复的方式逐步抓住需求，并且作为需求的实现软件系统必须能够迅速应对需求变化，需求变化有多快，软件变化就有多快。
因此，对于多变的需求，我们的解决之道是：引入灵活多变的架构，面向对象OO架构正是应对多变需求而生，强调软件的可维护性和拓展性，OO可能不是最好方式，但是目前是最合适的；对于复杂的需求，我们的解决之道是：委派专门的建模专家跟踪理解需求，在需求和需求实现之间搭建桥梁，项目方法上采取多次迭代的敏捷软件开发方式，逐步了解学习掌握需求。
在这里稍微说明一下，很多人总是将软件和数学、管理、财务混为一谈，其实软件本身就是一门独立的专业，是为数学、管理。
财务等专业领域服务的，不能期望软件人员也是其他领域专业人员，可是在中国现实中，很多人总是无法分辨，例如某局长将整个机关考核信息化的任务交给电脑中心，这就是将考核管理专业和软件专业混同的例子，在考核管理和软件之间需要一个领域建模专家，由他来理解或者设计考核管理体系，然后通过模型，表达成软件人员能够看懂的符号，软件人员通过模型了解领域。
曾经有需求专家呼吁：最好将需求给所有软件人员都了解，需求专家和一般软件人员一起工作，这些想法的本质是好的，但是不可能实现的，不可能每个软件人员不但了解软件架构和OO思想；还能够掌握另外一个专业领域的艰深知识，所以，现在我们提出：将领域专家建立的统一领域模型让所有软件人员都了解，让一般软件人员围绕领域模型工作，这样的方式才切实可行。
领域驱动设计PPT课件
10
Evans DDD
11
领域模型重要性
没有领域模型，只是靠代码编写完成一个又一 个功能，复杂的领域需求会使得他们无法交流 讨论，使工作陷入泥沼。
有少许领域模型，但是没有维护好模型与代码 直接的联系，两者产生差异，无法实现。
两个阶段目标不一致，导致分裂，项目失败。
16
分析模型
分析模型会有知识不断消化的过程，但在编码 时这些知识会被遗弃。
开发人员被迫为设计进行新的抽象，那么分析 人员嵌入模型中知识不能保留和重新发现。
分析模型很多重要发现更改往往出现在设计实 现过程，预先的模型可能深入研究无关主题， 忽视重要主题。
6
MDD/DDD优点
MDD bridges the gap between business and IT MDD在业务和IT之间 架设了桥梁 领域专家（或系统分析师）可以直接参与业务发展进程（见第7点）。 技术专家（软件应用）可以在一个更高的层次定义尽可能和领域概念的 定义声明有关模型。 通过在模型和模型实现之间定义一个重要的转换机制，就可以在业务和IT 技术之间建立一个桥梁，比如使用一个基于model-driven SOA的框架。
5
MDD/DDD优点
MDD empowers domain expertsMDD授权领域专家 业务领域专家能够注重建模，而技术专家可以专注于建立一个 MDD需要的框架或DSL等工具。一个软件系统不再只是程序编制 就可以了，领域专家可以通过符号（如文字，图形，表格）等直 接表达他们对业务领域的深入理解 。
使用DSL能够在设计时候就执行一下，这样，错误信息也是 domain-specific级别的，可见Static Verification: An External DSL Advantage一文。
ddd领域驱动 和solid设计原则
ddd领域驱动和solid设计原则DDD（Domain Driven Design）是一种软件开发方法论，它的核心是将业务领域的知识贯穿于整个软件系统的设计和开发过程中。
而SOLID是一组设计原则，用于指导面向对象编程中的类设计，以提高代码的可读性、可维护性和复用性。
本文将一步一步回答有关DDD和SOLID的问题，以帮助读者更好地理解这两个概念。
DDD是什么？DDD（Domain Driven Design）是Eric Evans在他的著作《领域驱动设计》中提出的一种软件开发方法论。
该方法论致力于将软件系统的设计与业务领域的知识紧密结合，以更好地满足业务需求。
DDD强调通过对领域模型的抽象、建模和讨论来推动软件设计，使得代码更加贴近业务思维，并且具有良好的可扩展性和可维护性。
SOLID是什么？SOLID是面向对象编程中的五个设计原则的首字母缩写，分别是单一职责原则（SRP）、开闭原则（OCP）、里氏替换原则（LSP）、接口隔离原则（ISP）和依赖反转原则（DIP）。
这些原则的目的是指导设计者编写高质量、可维护、可复用的代码。
使用这些原则可以使得软件系统的设计更加灵活、可扩展和易于维护。
如何应用DDD？应用DDD需要经历以下几个步骤：1. 深入理解业务领域：开发团队需要与业务专家密切合作，深入理解业务领域的知识和业务需求。
只有对业务本身有深刻的了解，才能更好地应用DDD。
2. 创建领域模型：基于对业务领域的理解，开发团队需要创建领域模型来抽象和表达业务中的概念和规则。
领域模型是DDD的核心部分，它能够帮助开发团队更好地理解业务，并指导系统的设计和实现。
3. 划分领域边界：在应用DDD时，需要根据业务需求划分领域边界。
将业务划分为多个领域，每个领域都有自己的领域模型和业务规则。
领域划分需要考虑业务的复杂度、可扩展性和可维护性等因素。
4. 实现领域模型：根据领域模型设计和实现相应的领域对象。
这些对象应该尽量贴近领域模型的语言和概念，以强化领域驱动的思维方式。
什么是领域驱动设计(DDD)架构
什么是领域驱动设计（DDD）架构领域驱动设计（Domain-Driven Design，DDD）架构是一种软件开发方法论，通过将软件设计过程中的关注点放在问题领域本身上，以更好地满足业务需求和解决复杂性问题。
DDD架构注重表达业务概念，并在技术实现中对其进行建模和映射，以便更好地理解和满足业务需求。
DDD架构的核心理念是将领域专家（Domain Experts）和技术人员聚集在一起，通过有效的沟通和合作，共同开发具有高内聚性和松耦合性的软件系统。
为了实现这一目标，DDD提供了一些关键概念和设计原则，下面将介绍其中的几个。
1. 领域模型（Domain Model）：领域模型是DDD架构中最重要的概念之一。
它是对业务领域中的重要概念、规则和关系的抽象和建模。
通过领域模型，我们可以深入理解业务需求，将其转化为可执行的软件模型。
2. 聚合（Aggregates）：聚合是领域模型中的一个重要概念，表示一组相关的对象或实体。
聚合内的对象之间有着明确的边界和关联关系，外部对象只能通过聚合根（Aggregate Root）来访问聚合内的其他对象。
这样可以确保数据的一致性和完整性。
3. 领域事件（Domain Events）：领域事件是对领域模型中重要业务动作的建模，它表示在领域中发生的一些重要事情。
领域事件可以触发其他领域对象的行为，也可以被其他领域对象所订阅和处理。
通过领域事件，我们可以实现领域模型中的业务流程和逻辑。
4. 值对象（Value Objects）：值对象是DDD中用于表示没有标识的、可替换的对象。
它们通常被用来描述领域模型中的属性或者一些固定的、不可变的值。
值对象具有值的语义，可以通过比较其属性来判断对象是否相等。
5. 聚合根和仓储（Aggregate Roots and Repositories）：聚合根是聚合中的一个重要对象，负责协调和控制聚合内的其他对象。
仓储则是将聚合根和聚合内的其他对象持久化到数据库或其他存储介质中的组件。
领域驱动架构及其演变史
领域驱动架构及其演变史领域驱动架构（Domain-Driven Design，简称DDD）是一种软件开发方法论，旨在解决复杂软件系统的设计与实现问题。
它将领域模型作为核心，通过对领域的深入理解和建模，将软件系统划分为多个领域，并在每个领域中应用相应的架构和设计模式。
领域驱动架构的演变史可以追溯到上世纪90年代初，当时软件开发行业面临着越来越复杂的业务需求和技术挑战。
传统的软件开发方法论主要关注技术实现，忽视了对业务领域的深入理解。
为了解决这个问题，一些先行者开始探索将领域模型引入软件开发过程的方法。
在这个背景下，埃里克·埃文斯（Eric Evans）于2003年出版了《领域驱动设计》一书，正式提出了领域驱动架构的概念。
该书详细介绍了如何通过领域模型来解决复杂软件系统的设计问题，并提出了一系列相关的设计原则和模式。
领域驱动架构的核心思想是将软件系统划分为多个领域，每个领域都包含一个明确定义的业务范围。
在每个领域中，开发团队与领域专家密切合作，深入理解业务需求，共同构建领域模型。
领域模型是对业务领域的抽象和建模，它包含了业务实体、值对象、聚合根、领域服务等概念，并定义了它们之间的关系和行为。
在领域驱动架构中，领域模型是核心，其他组件围绕着领域模型展开。
例如，应用层负责接收用户请求，调用领域服务进行业务处理；基础设施层负责与外部系统进行通信，提供数据持久化和其他支持服务。
领域驱动架构还引入了一些设计模式，如领域事件、聚合根、领域服务等，用于解决特定的设计问题。
随着时间的推移，领域驱动架构逐渐被开发者接受和应用。
人们发现，通过领域驱动架构，可以更好地理解和满足业务需求，提高软件系统的质量和可维护性。
同时，领域驱动架构也在不断演化和发展。
一方面，领域驱动架构的实践经验得到了总结和沉淀，形成了一些成熟的方法和工具。
例如，领域事件驱动架构（Event-Driven Architecture，EDA）借鉴了领域驱动架构的思想，将事件作为驱动系统的核心，实现了松耦合和可伸缩的系统设计。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 无需专业业务知识容易能理解能引起程序员的兴趣， 他们认为只有解决这些问题才能积累自己专业知识， 同时为自己简历增光添彩，这对于公司是浪费。
不注重核心领域的案例
• 银团贷款系统：大多数技术天才和技术高手都对数据库映 射层和消息接口津津乐道，而业务模型却交给一些刚刚涉 足面向对象技术的新手们打理。
• 一个无处不在(ubiquitous )的语言，项目中所有人统一交 流的语言。
• 减少沟通疑惑，减少传达走样。使得软件更加适合需求。
没有领域（边界）的模型
• 一个印在大纸张上的完整类图，整面墙都被它覆盖，花几 个月分析开发的领域模型，模型大多数对象都与其中三四 个对象有错综复杂的关系，且关系网几乎没有自然边界。 分析人员是忠于领域需求本质。
内聚
• 物体之所以成为物体，是因为其内聚机制。
• 内聚也就是一种组合组成关系，某个物体由哪些部分 组成，或者说由这些部分内聚聚合在一起。
• 通过内聚方式来切分领域，切分模型，寻找核心模型。
• 算法计算机制本身存在内聚性，使用策略模式等框架 把这些内聚计算分离出来，用一个明确接口来说明这 个框架的功能，将怎么做复杂细节交给框架去完成。
Evans DDD
领域模型重要性
• 没有领域模型，只是靠代码编写完成一个又一个功能，复 杂的领域需求会使得他们无法交流讨论，使工作陷入泥沼。
• 有少许领域模型，但是没有维护好模型与代码直接的联系， 两者产生差异，无法实现。
DDD优点
分析设计发展的三个阶段
• 第一阶段：围绕数据库的驱动设计，新项目总是从 设计数据库及其字段开始。
领域驱动建模(Evans DDD)
Evans DDD
• 2004年Eric Evans 发表Domain-Driven Design – Tackling Complexity in the Heart of Software （领域 驱动设计 ）简称Evans DDD
• 领域建模是一种艺术的技术，它是用来解决复杂软件快速 应付变化的解决之道
• 问题：开发人员开始实现应用程序时，彼此纠缠的关系根 本无法转换成可存储 可检索的实现。
• 是不是基于概念的模型类图不能成为程序设计的基础？
领域模型在软件架构中位置
什么是领域模型 Domain Model?
• 某个范围内的模型。首先是边界划分，在边界中寻找代表 领域本质旋律的模型。
• 领域模型只表达需求真实世界模型，和软件架构技术无关。 • 模型都是有前提和范围，或者称为有场景前提的。没有跨
• 设计人员的职责：必须指明一组能北项目中适应编程工具 构造的组件，这些组件必须能够在目标环境中有效执行， 并能够正确解决应用程序出现的问题
• 两个阶段目标不一致，导致分裂，项目失败。
新阶段：分析设计统一语言
• 统一领域模型，它同时满足分析原型和软件设计 ，如果 一个模型实现时不实用，重新寻找新模型。
结构图。组织结构图就是通用子域。 • 许多应用跟踪应收帐款 费用分类和其他帐务信息，这
些信息都可以使用通用的会计财务系统来处理。 • 有两个项目处理带时区功能的日期和时间组件，花费
最好的程序员数周时间，虽然必须做，但不是系统核 心。 • 考虑现有解决方案或开源公开模型来替代通用子域。 • 考虑外包，将通用子域外包，自己掌握核心领域。
• 第二层次：面向对象的分析设计方法诞生后，有了 专门的分析和设计阶段之分，分析阶段和设计阶段 是断裂的。
• 第三阶段：融合了分析阶段和设计阶段的领域驱动 设计（Evans: DDD）。
第一阶段：传统的数据库方式
• 过去软件系统分析设计总是从数据库开始，这种围绕 数据库分析设计的缺点非常明显：
• 1.分析方面：不能迅速有效全面分析需求。 • 2. 设计方面：导致过程化设计编程，丧失了面向对象
设计的优点。 • 2. 运行方面：导致软件运行时负载集中在数据库端，
系统性能难于扩展，闲置了中间件J2EE服务器处理性 能。 • 对象和关系数据库存在阻抗，本身是矛盾竞争的。
第二阶段：分析和设计分裂
• 计需求。
• 分析人员的职责：是负责从需求领域中收集基本概念。面 向需求。
• 尽管为持久领域对象提供详细注解文字说明，能够反映设 计思路，也设计了友好的用户界面。
• 这些特性都是外围，当这个软件最终交付用户使用时，差 劲程序员二次开发拓展时却依然搞得一塌糊涂，整个项目 差点失败。
通用子域：非核心领域
• 提炼核心领域，就必须剔除反面通用子域。 • 不同行业运输业 银行业 制造业都需要某种形式组织
领域模型切割
• 1.将复杂大的领域分割 成子领域。
• 2.抓住子领域的核心， 建立核心模型。
• 3.对核心模型实现灵活 性细节设计
旁门左道的快速开发
越范围的永恒不变的模型 。 • 由领域专家来定义领域模型。 • 名词==类名 动词==类中方法 服务或其他
机器人
机器人的领域模型
确定核心领域
• 大型系统中，有很多有用的组件，他们非常复杂，都 是软件成功不可或缺的，这样组件实在太多，以至于 领域模型的精髓部分变得不明显甚至被忽视。
• 不可能所有部分都进行提炼，分清轻重缓急，让领域 模型真正成为资产。
• 模型表达的“是什么”，是战略方向性，而不是”怎 么做”等技术细节。
• 设计中产生了一大堆用来实现算法 解决问题的方法， 而描述这个问题的方法变得模糊不清。怎么做的方法 在模型中泛滥成灾，表明模型存在某种问题。
• 算法或计算非常复杂，导致设计受到了冲击，模型中 的概念变成了用“怎么做”来解释，而不是用“是什 么”表达。
领域中寻找核心模型
• 找出核心模型，提供一种方法让我们很容易地从众多支持 模型中将它区分出来，将最有价值 最体现专门知识的概 念凸显出来，核心变小。
• 让最好的程序员来处理核心模型，根据需要调整人员的配 备，尽力找出核心的深层模型，对于其他部分投入必须经 过考虑，是否能为提炼出来的核心提供支持。
模型的特征