领域驱动设计核心概念
文章目录
- DDD特点
- 3种架构层次
- 战略模型
- 领域
- 限界上下文
- 架构
- 战术模型
- 实体 Entity
- 值对象 Value Object
- 聚合 Aggregate
- 聚合根、实体、值对象
- 领域服务
- 领域事件
- 模块
- 适配层
- 参考
DDD特点
- 使用充血领域对象，将数据和行为封装在一起，并与现实世界中的业务对象相映射，更加符合OO编程理念。
- 更容易抽象、分治业务，解决复杂问题。
- 相对的，如果逻辑简单，比如取数聚合，使用DDD的成本大于收益。
3种架构层次
- 架构设计分为：
- 业务架构——根据业务需求设计业务模块及其关系
- 系统架构——设计系统和子系统的模块
- 技术架构——决定采用的技术及框架
- DDD：聚焦业务架构，制定可演进的到系统架构的映射方案。
- 微服务：
- 设计可复用的和业务一致的系统架构。
- 追求系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。
战略模型
宏观上划分和集成限界上下文
领域
- 领域包含了问题域和解系统，可以映射为N个限界上下文。
限界上下文
- 划分：限界上下文应该从需求出发，按领域划分，遵循高内聚低耦合原则。
- 梳理关系：U上游，D下游。
- 合作关系（Partnership）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。
- 共享内核（Shared Kernel）：两个上下文依赖部分共享的模型。
- 客户方-供应方开发（Customer-Supplier Development）：上下文之间有组织的上下游依赖。
- 遵奉者（Conformist）：下游上下文只能盲目依赖上游上下文。
- 防腐层（Anticorruption Layer）：一个上下文通过一些适配和转换与另一个上下文交互。
- 开放主机服务（Open Host Service）：定义一种协议来让其他上下文来对本上下文进行访问。
- 发布语言（Published Language）：通常与OHS一起使用，用于定义开放主机的协议。
- 大泥球（Big Ball of Mud）：混杂在一起的上下文关系，边界不清晰。
- 另谋他路（SeparateWay）：两个完全没有任何联系的上下文。
- 不同限界上下文中的相同概念需要分别建模。
- 如创作上线文中的图书、物流上下文中的图书侧重点不同。
架构
- 通常六边形架构，领域模型位于核心。
战术模型
具体使用建模工具来细化限界上下文
实体 Entity
- 当一个对象由其标识（而不是属性）区分时，这种对象称为实体。如：人。
- 包含数据和行为。
- 建议将属性的验证放到实体中。
值对象 Value Object
- 当一个对象用于对事务进行描述而没有唯一标识时，它被称作值对象。如：颜色信息。
- 具有不变性、相等性（可度量领域中的某个东西、可进行比较）和可替换性。
- 需要保证值对象创建后就不能被修改。
聚合 Aggregate
- 一组相关对象的集合，作为一个整体被外界访问，集合的根节点是聚合根。
- 设计聚合的原则：
- 边界内的内容具有一致性：一个事务只修改一个聚合。如果难以实现考虑剥离聚合达到最终一致。
- 设计小聚合：大部分的聚合都可以只包含根实体，而无需包含其他实体。即使一定要包含，可以考虑将其创建为值对象。
- 通过唯一标识来引用其他聚合或实体。
- 边界外使用最终一致性。
聚合根、实体、值对象
- 区别：
- 从标识的角度：
- 聚合根具有全局的唯一标识；
- 实体只有在聚合内部有唯一的本地标识；
- 值对象没有唯一标识，不存在这个值对象或那个值对象的说法；
- 从是否只读的角度：
- 聚合根除了唯一标识外，其他所有状态信息都理论上可变；
- 实体是可变的；
- 值对象是只读的；
- 从生命周期的角度：
- 聚合根有独立的生命周期；
- 实体的生命周期从属于其所属的聚合，实体完全由其所属的聚合根负责管理维护；
- 值对象无生命周期可言，因为只是一个值；
- 从标识的角度：
- 关联：
- 聚合根到聚合根：通过ID关联；
- 聚合根到其内部的实体，直接对象引用；
- 聚合根到值对象，直接对象引用；
- 参考
领域服务
- 一些重要的跨实体的领域行为或操作，可以归类为领域服务。它既不是实体，也不是值对象的范畴。
- 执行一个显著的业务过程，如下单。
- 对领域对象转换。
- 输入多个领域对象，输出计算结果。
- 微服务中，一切领域逻辑（如通过聚合根暴露的业务逻辑）均需要通过领域服务对外暴露。
领域事件
- 作用：消除两阶段提交，支持聚合内一致性原则，维护聚合间的一致性。
模块
- 一种控制限界上下文的手段，一般尽量用一个模块来表示一个领域的限界上下文。
适配层
- 防腐层：一个上下文通过适配器和另一个上下文交互。
- 资源库：对领域的存储和访问进行统一管理。
参考
- 领域驱动设计在互联网业务开发中的实践
- 实现领域驱动设计
- 避免写流水账代码
领域驱动设计核心概念相关推荐
- 领域驱动设计-基本概念
我们略过需求的采集.直接进入需求分析与设计. 领域驱动设计(DDD)是近10年流行.比较成熟.比较成功的软件分析与设计方法.理论.我们早期常见的软件开发方式是拿到产品需求后,直接考虑数据库中表应该如何 ...
- 一、领域驱动设计核心思想与设计过程
一.软件发展的必然规律 1.软件是对真是世界的模拟,但真实世界软件十分复杂. 2.人在认识真实世界的时候总是有一个从简单到复杂的过程 3.软件需求的变更成为一种必然的事情,并且总是由简单向复杂转变 4 ...
- 领域驱动设计在讲什么
概述 概念可以简单描述某类事物,这类事物可以是实体也可以是问题.领域驱动设计是为了管理系统复杂性问题而生的一套方法论. 随着业务系统的复杂性不断提高,系统的性能和灵活性要求也会越来越高,如何构建一个扩 ...
- 【吐血推荐】领域驱动设计学习输出
一.Hello DDD 刚开始接触学习「DDD - 领域驱动」的时候,我被各种新颖的概念所吸引:「领域」.「领域驱动」.「子域」.「聚合」.「聚合根」.「值对象」.「通用语言」.....总之一大堆有关 ...
- 领域驱动设计，让程序员心中有码（八）
领域驱动是十五年前,由Eric Evans提出的解决软件工程复杂性问题的方法,作者从自己多年软件开发的角度出发,通过引入领域驱动设计的概念以及一系列战略设计模式和战术方法,为混沌的软件开发领域带来了一 ...
- 阿里文娱技术专家战獒: 领域驱动设计详解之What, Why, How?
战獒 阿里文娱技术专家 读完需要 8 分钟 速读仅需 3 分钟 阿里妹导读:什么是领域驱动设计?传统分层架构在实际开发中存在哪些问题?业务开发人员如何设计并搭建自己的领域模型?阿里文娱技术专家战獒将为 ...
- 领域驱动设计(DDD)在爱奇艺打赏业务的实践
领域驱动设计(Domain-Driven Design,以下简称DDD)思潮的形成要追述到30几年前,17年前,Eirc Evans定义了领域驱动设计的概念.DDD一直为传统行业的软件工程师提供软件设 ...
- 领域驱动设计的重要性
SOA.ESB.中台.微服务.分布式架构等一系列名词,都无法解决业务需求不断变化的及时响应,领域驱动设计的概念又重新流行了起来.没有领域模型,只是靠代码编写完成一个又一个功能,复杂的领域需求会使得他们 ...
- 领域驱动设计详解：是什么、为什么、怎么做？
简介:什么是领域驱动设计?传统分层架构在实际开发中存在哪些问题?业务开发人员如何设计并搭建自己的领域模型?阿里文娱技术专家战獒将为大家一一解答,并分享文娱在领域驱动设计上的实践. 一 什么是领域驱动设 ...
- soc 设计soc设计 uml实务手册_企业内训“领域建模和领域驱动设计”训练方案（2020年）...
※训练介绍※ 软件开发中,需求是解决"系统怎样好卖"的问题,设计是解决"降低开发成本"的问题.要降低成本,就要尽可能复用已有的各种资源. 目前大多数软件组织的复 ...
最新文章
- CMenu类的使用方法
- java课程设计图片浏览器_java课程设计图片浏览器
- bat贪吃蛇游戏代码_C语言写个贪吃蛇游戏
- iOS实现三屏复用循环广告[从服务器请求的广告]
- C语言函数题- 求矩阵不靠边元素之和
- html div初始隐藏点击可见_3种CSS3移动手机隐藏菜单UI界面代码解析/附源码下载...
- 面试官问：JS的继承
- 针对12306.cn网站应用架够的一些看法
- 【TensorFlow】TensorFlow从浅入深系列之十三 -- 教你深入理解模型持久化（模型保存、模型加载）
- linux 怎么看w7分区,如何查看widows7系统和Linux端口被占用
- swoole task 异步任务 注释请忽略 自己加的不一定对 别误导大家。。。。。。
- 【泛型高级-通配符】
- jquery ajax 删除确认,jquery 漂亮的删除确认和提交无刷新删除示例
- 回网友：不用PPT怎么做咨询顾问？
- SQL注入中information_schema的作用
- 双稳态电路的两个稳定状态是什么_555定时器原理知多少？四种应用电路分享
- Pillow图像几何变换
- OSPF —— 多区域部署 + ABR + ASBR + 路由重分发
- 密码学之恺撒加密(03)
- 触摸识别，智能分拣……看AI如何为垃圾分类赋能