DDD（领域驱动设计）概述
DDD（领域驱动设计概述）
- 定义
- 概述
- 核心概念
- 通用语言
- 特征
- 领域
- 子域
- 核心域
- 通用域
- 支撑域
- 限界上下文
- 划分原则
定义
- 领域驱动设计是一种处理高度复杂域的设计方法，试图分离技术实现的复杂性，围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演化等问题。团队应用它可以成功地开发复杂业务软件系统，使系统在演进时任然保持敏捷。
概述
- DDD不是语言，不是框架，不是架构，而是一种方法论，它可以分离业务复杂度和技术复杂度，DDD也并不是一个新的事物，它是面向对象的拔高，最终目标还是高内聚、低耦合。
- DDD的整个过程大概是这样的，开发团队和领域专家一起通过 通用语言 去理解和消化领域知识，从领域知识中提取和划分为一个一个的子领域（核心子域，通用子域，支撑子域），并在子领域上建立模型，再重复以上步骤，周而复始构建出一套符合当前领域的模型。
核心概念
通用语言
- 通用语言是一种沟通工具，在开发团队内部，开发团队与领域专家之间使用。它包含了自然语言、文档和图表（不一定是标准的UML图，只要能表达出领域知识的都可以）等内容。对通用语言中名词，动词的使用需要认真考量，这些名词和动词会指导后面模型的命名。
- 通用语言以领域专家的语言为基础，进一步进行规范化，或简化，或抽象，使得该语言既正确又容易理解，且不脱离领域专家的语言范畴。
- 在限界上下文之内的每种领域术语，词组或句子。它们在同一个上下文中具有唯一确定的含义，在限界上下文之外，它们可能表达不同的含义。
特征
- 必须在领域模型中表达。
- 统一了项目团队的员工表达语言。
- 消除了领域专家的不准确和矛盾。
- 不是领域专家强加的业务语言。
- 不是行业中使用的语言。
- 随着时间的推移而发展变化，它并不是完全在一次或几次会议中定义的，而是逐渐演变的。
领域
- 领域指的是一个特定的业务范围，大家在这个业务域范围内开展工作。一个系统可能由一个领域或者多个领域组成。在认识领域时一定要注意所指的业务域，行业、项目或系统都不能准确地表达领域所指的业务域。
- 领域用于确定边界，DDD会按规则细分业务领域，细分到一定程度，DDD会将问题范围限定在特定边界，在该边界内建立领域模型，进而用代码实现该领域模型，解决相应业务问题。
- 领域的核心思想是将问题域逐级细分，降低业务理解和系统实现的复杂度。
子域
- 子域是对领域从业务需求方面进行的拆分。由于领域的概念通常都过大，所以我们一般都会将其进行拆分，诸如核心域，通用域，支撑域。一般来讲核心域就是整个产品的业务价值所在。或者按照业务来拆分，诸如订单子域，产品子域，物流子域等。
- 通过领域划分，区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。
- 商业模式和战略方向决定公司在划分核心域、通用域和支撑域。不同的商业模式及战略方向决定划分也不相同。在公司领域细分、建立领域模型和系统建设时，要结合公司战略重点和商业模式，找到核心域，且重点关注核心域
核心域
- 业务成功的核心竞争力，决定产品和公司核心竞争力的子域是核心域。
通用域
- 不是核心，但被整个业务系统所使用 （可以直接购买的）。
- 没有太多个性化诉求，同时被多个子域使用的通用功能子域是通用域。比如认证、权限等，这类应用很容易买到，没有企业特点限制，无需太多定制化。
支撑域
- 不是核心，不被整个系统使用，完成业务的必要能力（可以外包出去的）。
- 既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，但又是必需的支撑域。支撑域具有企业特性，但不具通用性，例如数据代码类的数据字典等系统。
限界上下文
- 限界上下文是一个边界，领域模型便存在在这个边界之内。当模型被一个显示的边界所包围时，其中每个概念的含义便是确定的了。因此，限界上下文主要是一个语义上的边界。
- 对于通用语言，限界上下文是语言的边界，对于领域模型，限界上下文是模型的边界，二者对应于问题空间（Problem Space）的界定。 对于系统的架构，限界上下文还确定了应用边界和技术边界，进而帮助我们确定整个系统及各个限界上下文的解决方案。
- 原则上，一个上下文就对应一个子域。但这并不是绝对的，限界上下文的目的是为了更加明确领域模型的职责和范围，是从“解决方案空间”来考虑问题的。通常来说，一个限界上下文可以是一个微服务，或者一个模块。
划分原则
- 概念相同，含义不同：如果一个模型在一个上下文里面有歧义，那有歧义的地方就是边界所在，应该把它们拆到不同的限界上下文中。
- 外部系统：有时候系统需要同外部系统打交道，这个时候可以把与外部系统打交道的那部分拆分出去以实现更好的扩展性。这样一旦外部系统发生了变化，就不会影响到我们的核心业务逻辑。
- 组织扩展：尽量不要两个团队一起在一个限界上下文里面开发，因为这样可能会存在沟通不顺畅、集成困难等问题。
DDD（领域驱动设计）概述相关推荐
- DDD领域驱动设计浅谈
DDD领域驱动设计是什么 1 DDD是什么? DDD是领域驱动设计,是Eric Evans于2003年提出的,离现在有17年. DDD名为:Domain Driven Design (领域驱动设计) ...
- DDD领域驱动设计-视频讲解+实战
目录 简介 解决的问题 过度耦合 现状 DDD的分层架构和构成要素 小结 分包应用 DDD领域驱动设计:实体.值对象.聚合根 DDD应用 战略建模 领域 限界上下文 需求分析 上下文映射图 战术建模- ...
- DDD领域驱动设计之聚合、实体、值对象
关于具体需求,请看前面的博文:DDD领域驱动设计实践篇之如何提取模型,下面是具体的实体.聚合.值对象的代码,不想多说什么是实体.聚合等概念,相信理论的东西大家已经知晓了.本人对DDD表示好奇,没有在真 ...
- DDD领域驱动设计 — 贫血模型与充血模型
文章转载来源:https://juejin.cn/post/6917125801460629518 | 前言 要想深入掌握和了解 DDD 领域驱动设计的核心,那无论如何也绕不开两大较为抽象的概念-- ...
- DDD 领域驱动设计：贫血模型、充血模型的深入解读！
作者:JavaEdge在掘金 链接:https://juejin.cn/post/6917125801460629518 - 前言 - 要想深入掌握和了解 DDD 领域驱动设计的核心, ...
- 浅谈我对DDD领域驱动设计的理解
从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品 ...
- C#进阶系列——DDD领域驱动设计初探（五）：AutoMapper使用
前言:前篇搭建了下WCF的代码,就提到了DTO的概念,对于为什么要有这么一个DTO的对象,上章可能对于这点不太详尽,在此不厌其烦再来提提它的作用: 从安全上面考虑,领域Model都带有领域业务,让Cl ...
- DDD 领域驱动设计：贫血模型、充血模型的深入解读
点击上方"朱小厮的博客",选择"设为星标" 后台回复"书",获取 后台回复"k8s",可领取k8s资料 - 前言 ...
- [转]浅析DDD(领域驱动设计)
最近在做一些微服务相关的设计,内容包括服务的划分,Restful API的设计等.其中比较棘手的就是Service的职责划分:如何抽象具有统一业务范畴的Model,使其模块化,又如何高度提炼并组合多模 ...
- 浅析DDD(领域驱动设计)
最近在做一些微服务相关的设计,内容包括服务的划分,Restful API的设计等.其中比较棘手的就是Service的职责划分:如何抽象具有统一业务范畴的Model,使其模块化,又如何高度提炼并组合多模 ...
最新文章
- 【Verilog HDL 训练】第 08 天（二进制、Johnson、环形计数器）
- 基于双向匹配的陌生人社交策略及算法思考
- 大咖云集！Kubernetes and Cloud Native Meetup 深圳站开始报名！
- 你真的认真想过了吗？
- nmap配合shell使用
- 关于逐项作用函数的用法
- 《非暴力沟通》读书笔记
- 浅谈对称加密与非对称加密
- C4D双十一促销海报模板,参考一下！
- Form表单的五个属性
- [导入]更新：让UpdatePanel支持上传文件
- yum离线下载rpm包
- VS2010对Excel操作---DLL向
- jenkins构建执行shell 所有命令出现command not found
- 中国省份名称的映射字典
- 自用PHP版H5微信公众号吸粉引流的恶搞小游戏 当天收获500+粉丝
- 计算机字节换算在线,计算机字节换算(计算机字节换算器)
- 浅析json_encode
- 重新认识受控和非受控组件
- HRBUST1313-火影忍者之～静音