前端直播网站怎么做,做电影ppt模板下载网站,建设银行网站 开户行怎么查,哈尔滨网站建设流程尼恩说在前面
在40岁老架构师 尼恩的读者交流群(50)中#xff0c;最近有小伙伴拿到了一线互联网企业如阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格#xff0c;遇到很多很重要的面试题#xff1a; 谈谈你的DDD落地经验#xff1f; 谈谈你对DDD的理解#x…尼恩说在前面
在40岁老架构师 尼恩的读者交流群(50)中最近有小伙伴拿到了一线互联网企业如阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格遇到很多很重要的面试题 谈谈你的DDD落地经验 谈谈你对DDD的理解 如何保证RPC代码不会腐烂升级能力强? 微服务如何拆分 微服务爆炸如何解决 你们的项目DDD是怎么落地实操的 所以这里尼恩给大家做一下系统化、体系化的梳理使得大家可以充分展示一下大家雄厚的 “技术肌肉”让面试官爱到 “不能自已、口水直流”。
也一并把这个题目以及参考答案收入咱们的 《尼恩Java面试宝典PDF》V144版本供后面的小伙伴参考提升大家的 3高 架构、设计、开发水平。 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF请到文末公号【技术自由圈】取 除了本文尼恩输出了一个 《从0到1带大家精通DDD》系列帮助大家彻底掌握DDD链接地址是
《阿里DDD大佬从0到1带大家精通DDD》
《阿里大佬DDD 落地两大步骤以及Repository核心模式》
《阿里大佬DDD 领域层该如何设计》
《极兔面试微服务爆炸如何解决Uber 是怎么解决2200个微服务爆炸的》
《阿里大佬DDD中Interface层、Application层的设计规范》
《字节面试请说一下DDD的流程用电商系统为场景》
《DDD如何落地去哪儿的DDD架构实操之路》
《DDD落地从腾讯视频DDD重构之路看DDD极大价值》
《DDD落地从美团抽奖平台看DDD在大厂如何落地》
《美团面试微服务如何拆分原则是什么》
《DDD神药去哪儿结合DDD实现架构大调优》
《DDD落地从网易新闻APP重构看DDD的巨大价值》
《DDD落地从阿里单据系统看DDD在大厂如何落地》
《DDD落地有赞的生产项目DDD如何落地》
《DDD落地从携程订单系统重构看DDD的巨大价值》
《DDD落地京东的微服务生产项目DDD如何落地》
《DDD落地阿里供应链商品域DDD如何落地》
《240Wqps美团用户中台 如何使用DDD架构》
大家可以先看前面的文章再来看本篇效果更佳。
另外尼恩会结合一个工业级DDD实操项目在第34章视频《DDD的学习圣经》中给大家彻底介绍一下DDD的实操、COLA 框架、DDD的面试题。
DDD现在非常火爆是有其巨大生产价值经济价值的 绝不仅仅是一套概念那么简单。
DDD的绝大价值具体请参见以下视频 从腾讯视频DDD重构案例看看DDD极大价值 文章目录 尼恩说在前面爱奇艺打赏业务DDD实践价值领域驱动设计是什么DDD打赏业务实践1、打赏业务简介2、战略设计六边形架构 3、战术设计 DDD的优势几个关键问题结束语说在最后技术自由的实现路径 PDF实现你的 架构自由实现你的 响应式 自由实现你的 spring cloud 自由实现你的 linux 自由实现你的 网络 自由实现你的 分布式锁 自由实现你的 王者组件 自由实现你的 面试题 自由 爱奇艺打赏业务DDD实践
作者爱奇艺会员技术团队
领域驱动设计(Domain-Driven Design以下简称DDD)思潮的形成要追述到30几年前17年前Eirc Evans定义了领域驱动设计的概念。
DDD为传统行业的软件工程师提供了一种新的设计方法论但在互联网领域的应用却相对较少。
然而随着互联网行业对业务复杂性的应对以及对微服务架构的偏好DDD再次回到了人们的视线之中。本文将主要探讨如何应对软件复杂性问题。
互联网的行业的业务越来越复杂面临与传统行业软件相同的问题微服务的流行带火了DDD以解决微服务拆分问题。
本文主要对第一点“解决软件复杂性之道”进行讲解。
价值
详细讲解之前我们先给出DDD为打赏业务带来的价值。
会员业务部门在打赏业务中实践 DDD 后取得了以下显著成果
新需求接入开发成本节约20%更换底层中间件开发成本节约20%项目熟悉成本节约30%(对DDD有基本了解为前提)单测开发成本指数级降低上线风险、成本降低。
了解了DDD流行的背景及业务价值后下面我们对DDD是什么、有哪些优势、项目中如何实践以及几个关键问题进行叙述。
领域驱动设计是什么
讨论领域驱动设计是什么之前我们先看下面一段代码 这是一个打赏接口定义单看这个接口是没有问题的用户基于活动选择明星选择道具进行打赏。
业务逻辑上没问题但我们会发现一些代码的坏味道。
代码编译后方法的参数名会丢失。 在编码过程中如果明星和道具的参数顺序传递错误代码仍可顺利编译但只有在运行时才会暴露出业务错误。尽管这种问题的发现成本相对较低但在编译阶段就能发现并避免这类错误可以降低问题的排查成本。在上述方法中参数编码可以唯一标识实体但失去了实体在业务领域的实际意义例如为特定明星赠送特定道具。
在打赏业务逻辑中存在大量与核心业务无关的前置校验逻辑这会影响代码的可读性。所有逻辑都堆叠在一个方法中增加了编写测试用例的复杂度。
这些问题出现的根本原因在于对业务领域的划分不够明确仅仅实现了操作流程缺乏领域抽象。方法参数定义缺少业务领域含义。实际上活动校验本质上是活动属性判断活动是否有效取决于活动自身的属性。可以将活动校验抽象为 ActivityValidate 类或在实体中增加 validate 方法。更进一步可以将校验逻辑直接放在活动的构造方法中既能达到校验目的又避免漏校验。这样在编写单元测试时将大逻辑拆分为多个逻辑单元可以大大减少用例数量。优化后的代码如下 针对活动校验我们可以采用构造函数校验因此在打赏方法中无需再进行校验。将活动校验放在前置构造函数中有助于降低测试用例数量。
回到最初的问题什么是领域驱动设计
1、领域驱动设计基于领域建模而非数据建模
在上面的例子中重构前 activity 实体仅具有基本属性和 get/set 方法即“失血模型”。这导致 activity 作为领域对象退化为数据对象仅用于 ORM 组件的 CRUD 操作。失血模型在项目代码中随处可见。其原因与对象-关系映射ORM如 Hibernate持久化机制的流行直接相关。使用 ORM 将每个类映射到一张数据表通过实体对象完成 CRUD 操作久而久之实体成为 ORM 框架的专用名词失去了领域能力。在进行项目设计时应从业务领域角度出发而非数据库角度。我们将在战略设计部分详细讨论这一问题。
2、满足六边形架构设计
六边形架构将在后续章节中详细介绍洋葱架构、干净架构与六边形架构相似。
满足以上两点并对 DDD 的一些概念进行映射实践那么你的系统已符合 DDD。总结来说DDD 并非一套全新的特殊架构而是项目代码经过重构满足高可维护性、高可扩展性、高可测试性、代码结构清晰之后必然达到的终点。
领域驱动设计DDD是一种软件设计方法它强调基于领域建模而非数据建模关注六边形架构设计。通过实践 DDD我们可以更好地应对业务复杂性实现软件系统的卓越表现。在实际项目中根据业务需求和场景灵活运用 DDD 理念和相关架构构建高质量、高可维护和易于扩展的软件系统。
DDD打赏业务实践
1、打赏业务简介 观看视频时选择明星、礼物进行打赏 打赏后屏幕有气泡提示 打赏数据在排行榜进行显示 累计一定的打赏获得某种奖励。
2、战略设计
在谈论战略设计时我们必须了解几个核心概念领域、子域、限界上下文和架构分层。
领域广义上讲领域代表了组织所从事的业务范围及其涉及的所有内容。每个公司或组织都有其独特的业务领域和运营方式这个领域即为该公司或组织的业务范围及在其中进行的活动。当你为某个企业开发软件时你所面对的就是这个企业的领域。对于你来说这个领域应该是清晰明确的因为你是在这个领域内开展工作。
对于打赏这种业务打赏本身便是领域即打赏领域。无论你的打赏对象是一位主播、一部电影或者一篇博文又无论你的打赏道具是RMB、虚拟币、火箭等等打赏都是这个领域的核心。
子域领域模型可能会让我们认为整个业务系统应该构建一个单一、紧凑、功能齐全的模型。然而这并不是 DDD 的目标。相反在 DDD 中一个领域被划分为多个子领域。这些子领域有助于我们更加关注业务系统的某一特定方面从而实现领域的有效拆分。
限界上下文限界上下文是一个具有明确边界的特定职责范围。在这个范围内领域模型中的每个概念包括属性和操作都有其特定的含义。
打赏系统搭建之初需求比较简单随着业务的发展需求不断复杂化领域拆分及迭代如下 初期运营和产品需求简单只需实现免费打赏功能并在界面展示打赏气泡因此将整个系统划分为一个领域 经过一段时间的试水发现活动效果不错需求方希望增加支持多场打赏活动。为了实现这个目标我们需要新增活动支撑子领域 随着需求的进一步升级用户在达到一定打赏额度后可以获得奖品。为了实现这个功能我们引入了奖励子领域 为了提高用户的参与度我们增设了排行榜功能从而引入了排行榜子领域。
最终领域划分如下图 打赏核心子域完成打赏操作。 通知子域实现界面气泡通知能力。 奖励子域奖励策略匹配奖励发放。 排行子域完成排行功能。 活动子域活动、明星、道具管理。 用户子域完成用户查询、校验等通用能力。
领域的拆分过程并没有上面描述的那么顺利经历了很多推翻重来的过程正是经历了这些过程我们对领域的理解才能更深入更符合领域建模。
架构分层分层架构的一个关键原则是每层只能与下方层发生聚合。 为了解耦接口定义与实现我们将接口定义在领域层实现定义在基础设施层。但这样违反了从顶至底的单项依赖原则。
为了解决这个问题我们采用依赖倒置原则——高层模块不应该依赖于低层模块两者都应该依赖于抽象。抽象不应该依赖于细节细节应该依赖于抽象。
根据此原则结构调整如下 我们将基础设施层置于所有层次结构的顶部使其能够实现其他层次定义的接口。
在分层架构中遵循依赖倒置原则可能会发现分层概念实际上已不再存在。无论是高层次还是低层次它们都仅依赖于抽象。
这样一来整个分层结构仿佛被推平客户可以以“平等”的方式与系统交互。当加入新的客户时它们仅作为不同的输入、输出以及展示形式这就是我们将要了解的另一种架构——六边形架构。 六边形架构
在我们的代码库中有许多直接的外部依赖和实现细节例如 MyBatis 的 Mapper 类、HttpClient 注入、RocketMQ 的监听、缓存的直接操作等。
这种实现方式有两个明显的问题 一是当底层更换基础组件时会对业务逻辑产生直接影响导致代码修改量和测试范围大幅增加 二是缺乏功能复用性若其他业务有类似逻辑无法直接移植和复用。
于 2005 年Alistair Cockburn 提出了六边形架构亦称为端口和适配器架构。
从上图可以看出针对核心的应用程序和领域模型其他底层依赖或实现都可以抽象为输入和输出两类。
组织关系变成了一个二维的内外关系而非上下结构。每个 I/O 与应用程序之间都有适配器进行隔离每个最外围的边都代表一个端口。
基于六边形架构设计的系统是领域驱动设计DDD所追求的最终形态。六边形架构的实践将在“DDD 优势”部分进行详细阐述。
先给出基于六边形架构实践后项目模块结构 模块说明Admin-api配置后台相关api对外用户接口application应用domain领域infrastructure基础设施query查询模块task与使用的中间件相关可忽略worker处理事件消息模块common基础包
通过六边形架构我们可以更有效地实现领域模型的内外分离降低外部依赖提高代码的可维护性和复用性。在实际项目中我们可以根据业务需求和场景灵活运用六边形架构将底层实现与领域模型分离使代码更具灵活性和可扩展性。六边形架构有助于我们实现高质量、高可用的软件系统满足不断变化的业务需求。
3、战术设计
在战略设计的基础上领域边界已清晰可见。接下来我们讨论战术设计首先对领域驱动设计DDD的几个基本概念进行业务映射。
实体由属性和行为组成具有唯一标识。
在设计系统时我们往往侧重于数据而非领域。对于 DDD 开发者来说这种情况同样存在因为在软件开发中数据库仍然占据主导地位。首先考虑的是数据的属性和关联关系而非具有丰富行为的领域概念。
这种做法的结果是将数据模型直接映射到对象模型上导致实体仅包含 get/set 方法这并非 DDD 的风格。
只有get/set实体需配合service使用内聚性、可维护性以及复用迁移成本均明显高于DDD的做法。 值对象没有唯一标识具有可度量或可描述并满足不变性的对象。
我们应该尽量使用值对象来建模而不是实体对象因为相比实体我们可以非常容易地对值对象进行创建、测试、使用、优化和维护。 对于第一种实现用户必须了解同时使用 amount 和 currency并清楚如何运用这两个属性。这是因为这两个属性并未构成一个概念整体。对于 PropName 值对象的定义可以带来一定的扩展性。例如如果需要对道具名称进行大小写转换可以在 PropName 内部实现此操作而无需将相关逻辑泄漏到 Prop 中。
领域服务
领域服务表示一个无状态的操作用于实现特定于某个领域的任务。
当某个操作不适合放在聚合和值对象上时最好的方式便是使用领域服务了。
例如“用户认证”一种方式是我们可以简单地将认证操作放在实体上。
对于这种设计存在两个问题。 首先用户类需要知道某些认证细节 其次这种方法也不能显示的表达通用语言。
这里我们询问的是一个User“是否被认证了”而没有表达出“认证”这个过程。
在有可能的情况下我们应该尽量使用建模术语直接地表达出交流语言。
领域事件领域专家所关心的发生在领域中的一些事件。我们通常将领域事件用于维护事件的一致性这样可以消除两阶段提交(全局事务)。
聚合聚合是一组相关对象的组合作为一个整体被外界访问聚合根是这个聚合的根节点。
聚合是核心领域的重要概念它可以用来说明领域内的关系。
此外聚合在技术上也有很高的价值可以指导详细设计。聚合由根实体、实体、值对象组成。
工厂工厂提供一个创建对象的接口封装了所有创建对象的复杂操作过程。
同时客户无需直接引用实际被创建的对象。 在实际应用中我们可以根据业务需求和场景灵活运用工厂模式。工厂模式可以简化对象创建的过程提高代码的可维护性和可扩展性。通过封装创建对象的复杂操作工厂模式还可以降低代码之间的耦合度便于后续的优化和扩展。在项目中我们可以根据实际需求定义不同的工厂类来创建相应的对象从而实现对象的灵活创建和管理。
DDD的优势
应用DDD的系统符合六边形架构我们实现了以下目标 独立于框架架构不应该依赖某个外部的库或者框架不应该被框架的结构所束缚 独立于UI前台展示的样式可能会随时发生变化但是底层架构不应该随之而变化 独立于底层数据源软件架构不应该因为不同的底层数据存储而产生巨大改变 独立于外部依赖无论外部依赖如何变更、升级业务的核心逻辑不应随之而大幅变化。
为实现以上目标六边形架构如洋葱架构、干净架构等是个合适的选择。接下来结合打赏具体业务实现讲解如何实现这些目标。
先给出项目某个模块的代码包结构 资源库将资源库作为业务与数据的隔离层屏蔽底层数据表细节同时完成 PO 与 DO 的转化。DO 与 PO 的转化有利于领域层不直接依赖底层实现便于后续更换底层实现或功能迁移。资源库接口定义在领域层接口实现在基础设施层。 RPCRPC 部分的结构拆分与资源库类似区别在于存在领域服务。接口定义放在领域层具体实现在基础设施层。 在遵循六边形架构的大原则下其他边的拆分也变得清晰简单了此处不再赘述。
通过以上实践我们可以看到 DDD 在实际应用中的优势
灵活性基于领域驱动设计的系统具有较高的灵活性可以轻松应对业务变化和需求变更。可维护性领域驱动设计将业务逻辑与技术实现分离使得代码更具可读性和可维护性。复用性通过领域服务、聚合等概念实现业务逻辑的复用降低开发成本。扩展性领域驱动设计有助于提高系统的扩展性方便引入新功能和模块。降低耦合度通过六边形架构将业务层与底层技术层分离降低系统耦合度便于后续迭代和升级。
总之应用 DDD 可以让我们更好地应对复杂多变的业务挑战实现软件开发的卓越表现。在实际项目中我们可以根据业务需求和场景灵活运用 DDD 理念和相关架构构建高质量、高可维护和易于扩展的软件系统。
几个关键问题
1、事务
在上文中“聚合”章节我们讨论了事务即在一次事务中只操作一个聚合实例。如果发现一次事务内的逻辑过多可以考虑将部分逻辑剥离为独立的聚合采用最终一致性。基于这个基础应用层是最适合声明事务的层次。
2、查询
CQRS命令查询职责分离在 DDD 中是一种常见的模式。它将领域模型与查询功能分离让复杂的查询摆脱领域模型的限制以更简单的 DTO 形式展现查询结果。同时CQRS 还分离了不同的数据存储结构让开发者可以根据查询功能和需求更自由地选择数据存储引擎。具体实践可参考相关资料。
3、框架无关
六边形架构设计已实现与底层实现、框架、中间件无关。但还有一个较大的框架依赖即 Spring。我们的解决方案是在领域内使用的 Spring Bean 通过传参方式实现领域层与框架的解耦。
4、成本
在实践 DDD 时成本是一个重要考虑因素包括学习成本、改造成本、兼容成本等。在实际操作前建议先评估好成本。
结束语
领域驱动设计DDD并非一套全新的特殊架构而是一种应对软件复杂性的方法论。它基于面向领域建模六边形架构以及经过重构的项目代码旨在实现高可维护性、高可扩展性、高可测试性和代码结构清晰。遵循这一方法我们将能够更好地应对复杂多变的业务挑战实现软件开发的卓越表现。
说在最后
DDD架构如何落地是非常常见的面试题。
以上的内容如果大家能对答如流如数家珍基本上 面试官会被你 震惊到、吸引到。
在面试之前建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》并且在刷题过程中如果有啥问题大家可以来 找 40岁老架构师尼恩交流。
最终让面试官爱到 “不能自已、口水直流”。offer 也就来了。
当然关于DDD尼恩即将给大家发布一波视频 《第34章DDD的学习圣经》 帮助大家彻底穿透DDD。 技术自由的实现路径 PDF
实现你的 架构自由
《吃透8图1模板人人可以做架构》
《10Wqps评论中台如何架构B站是这么做的》
《阿里二面千万级、亿级数据如何性能优化 教科书级 答案来了》
《峰值21WQps、亿级DAU小游戏《羊了个羊》是怎么架构的》
《100亿级订单怎么调度来一个大厂的极品方案》
《2个大厂 100亿级 超大流量 红包 架构方案》
… 更多架构文章正在添加中
实现你的 响应式 自由
《响应式圣经10W字实现Spring响应式编程自由》
这是老版本 《Flux、Mono、Reactor 实战史上最全》
实现你的 spring cloud 自由
《Spring cloud Alibaba 学习圣经》
《分库分表 Sharding-JDBC 底层原理、核心实战史上最全》
《一文搞定SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系史上最全》
实现你的 linux 自由
《Linux命令大全2W多字一次实现Linux自由》
实现你的 网络 自由
《TCP协议详解 (史上最全)》
《网络三张表ARP表, MAC表, 路由表实现你的网络自由》
实现你的 分布式锁 自由
《Redis分布式锁图解 - 秒懂 - 史上最全》
《Zookeeper 分布式锁 - 图解 - 秒懂》
实现你的 王者组件 自由
《队列之王 Disruptor 原理、架构、源码 一文穿透》
《缓存之王Caffeine 源码、架构、原理史上最全10W字 超级长文》
《缓存之王Caffeine 的使用史上最全》
《Java Agent 探针、字节码增强 ByteBuddy史上最全》
实现你的 面试题 自由
4000页《尼恩Java面试宝典 》 40个专题
以上尼恩 架构笔记、面试题 的PDF文件更新▼请到下面【技术自由圈】公号取 ▼
