【实践篇】最全的【DDD领域建模】小白学习手册(文末附资料)

实践,最全,ddd,领域建模,小白,学习,手册,文末,资料 · 浏览次数 : 42

小编点评

**标题:领域驱动设计:从理论到实践** **内容:** *概述领域驱动设计 (DDD),以及它与其他设计模式的关系。 *介绍DDD的基本架构,包括实体、值对象、服务和事件。 *描述DDD的聚合和事件处理机制。 *分析DDD在不同领域中的应用,例如REST API、数据库和事件驱排序。 *提供实际的DDD案例,包括数据库事务、事件ourcing和CQRS架构。 *解释DDD的值对象和实体的概念。 *描述DDD的仓储模式,以及如何使用Spring Data JDBC。 *介绍DDD的最终大招——By Experience。 *分享领域驱动设计的实践和反思。 *提供一些DDD案例的参考博客。 **排版:** *标题:领域驱动设计:从理论到实践 *内容: *概述 *介绍DDD的基本架构 *描述DDD的聚合和事件处理机制 *分析DDD在不同领域中的应用 *提供实际的DDD案例 *解释DDD的值对象和实体的概念 *描述DDD的仓储模式,以及如何使用Spring Data JDBC *介绍DDD的最终大招——By Experience。 *分享领域驱动设计的实践和反思 *提供一些DDD案例的参考博客。

正文

导读

DDD领域建模被各个大小厂商提起并应用,而每个人都有自己的理解,本文就是针对小白,系统地讲解DDD到底是什么,解决了什么问题,及一些建议和实践。本文主要是思想的一种碰撞和分享,希望能对朋友们有所启发或帮助。

1、前言:

在当时的环境下,单体应用仍然是市场的主体,但是大型复杂软件系统已经出现,给团队的设计和开发工作带来了比较大的挑战。

DDD提供了一种新的设计思路,通过对于业务子域和限界上下文的划分,建立跨越业务和技术的统一语言,为业务建模的同时,拉通业务和技术实现。

DDD理论的提出,对整个软件架构设计领域,尤其是对微服务架构的设计产生了巨大的影响。那我们如何运用DDD来解决所面临的大型业务系统问题呢?

在这里我们以中台业务为例,进行实践和应用。

友情提示:看目录,从整体中深入内部去看

2、目前我们的现状:

2.1软件设计所面临的挑战

•软件开发的不不确定性贯穿了了整个软件工程 的⽣生命周期。

•软件⼯程中不不可能有任何“银弹”解决软件 的复杂度问题。

•软件⼯程核⼼实质是社会⼯程,优秀团队 的竞争力来源于互相的信任及良好的沟通。

2.2软件工程的复杂度:

•无法回避这种复杂性,所做的只有控制这种复杂 性。20多年年前,顶尖的软件设计人员已经意识到

•领域建模和设计的重要性。尽管没有被清楚的表 述出来,在对象社区涌动着⼀种新的思潮,Eric Evans把它称为领域驱动设计。

•领域驱动设计是 一种思维方式,也是一组优先任务,它旨在加速 那些必须处理理复杂领域的软件项⽬的开发。

初衷及目标:高内聚,低耦合

3、和传统架构设计相比DDD解决的问题

DDD要解决的两个核心问题:

1.业务架构如何合理的设计?

2.如何使系统架构域业务架构保持一致并具备可持续的扩展?

领域驱动的设计基本目标:有效建模,并运⽤用领域模型驱动团队进⾏行行沟通分析、设计及开发。

4、领域驱设计的核心思想:

1、模型与现实业务的统一

•模型和程序设计的核心相互影响。正是模型与实现之间的紧密联系才使模型变得有⽤, 并确保我们在模型中所进行的分析能够转化为最终程序。

•模型与实现之间的这种紧密结合 在维护和后续开发期间也会很有用,因为我们可以基于对模型的理理解来解释代码。

2、统一(业务和技术)语言

•模型是团队所有成员使用的通⽤语⾔的中枢。由于模型与实现之间的关联,开发人员可 以⽤该语⾔来讨论程序。

•他们可以在无需翻译的情况下与领域专家进行沟通。⽽且由于该语言是基于模型的,因此我们可借助自然语⾔对模型本身进行精化。

3、团队的持续学习,消化知识,系统持续的发展

模型是浓缩的知识。模型是团队一致认同的领域知识的组织⽅式和重要元素的区分⽅ 式。透过我们如何选择术语、分解概念以及将概念联系起来,模型纪录了我们看待领域的⽅式。

当开发⼈员和领域专家在将信息组织为模型时,这一共同的语⾔(模型)能够促使 他们⾼效地协作。

4、领域驱动设计三原则

P1: Focus on your core domain.

※ 聚焦于你的 核心领域

P2: Iteratively explore models in a creative collaboration of domain practitioners and software practitioners.

※ 通过协作 迭代 探索模型

P3: Speak a Ubiquitous Language within an explicitly Bounded Context.

※ 统一语言

5、领域驱动的设计步骤:

5.1、统一语言

同一对象在不同上下文中的概念可能是不同的。

领域太复杂,只有在分割的上下文内才可能形成统一语言。

在UML作为建模主流的时代,软件设计被明确分为面向对象分析(OOA),面向对象设计(OOD)和面向对象编码(OOP)阶段。

实际操作中OOD的工作往往被OOA和OOP各自承担一部分,并同时存在分析模型和设计模型两个割裂的模型。

领域驱动设计的核心是建立统一的领域模型。领域模型在软件架构中处于核心地位,软件开发过程中,必须以建立领域模型为中心,以保障领域模型的忠实体现。

简单理解起来的话,也就是把业务人员和开发人员的语言统一起来,用代码来感受一下大概就是:

userService.love(Jack, Rose) => Jack.love(Rose)
companyService.hire(company,employee) => 
Company.hire(employee)

5.2、领域内的事件风暴、命令风暴

领域建模的分析过程及方法:

5.2.1、 什么是领域事件?

- 捕获我们所建模的领域中所发⽣生过的事 情

“ 任何的业务事件都会以某种数据的形式 留留下⾜足迹。我们对于事件的追溯可以通过 对数据的追溯来完成。......你⽆法回到从 前去看看到底发⽣了什么,

但是却可以在 单据的基础上,⼀一定程度的还原当时事情 发⽣的场景。当我们把这些数据的⾜迹按 照时间顺序排列列起来,我们⼏乎可以清晰 的推测出这个在过往的⼀段时间内到底发 ⽣了那些事情 ”

要点:

_1、业务关心的事件 :_一个领域事件必须对业务有价值,有助于形成完整的业务闭环,也即一个领域事件将导致进一步的业务操作。

2、用“已发生”时态描述

3、有时间顺序

5.2.2 、如何进行命令风暴?

围绕第一步识别出的领域事件, 针对各个事件进行命令分析。 什么样的命令导致的这个事件的发生。

有的命令可能产生多个事件,可以使用箭头将它们连接

5.2.3、 寻找聚合

5.2.3.1什么是聚合

持续探索

在领域驱动设计中,聚合是⼀一组相关领 域对象,其⽬目的是要确保业务规则在领 域对象的各个⽣命周期都得以执行:

‣ 聚合边界内保证业务不不变性(invariant)

‣ 只能通过聚合根修改边界内的对象

‣ 聚合根有全局标识

5.2.4、 持续探索:

领域驱动开发强调维护应⽤程序模型的概 念完整性。但如果不不对模型的概念完整性 进行妥协的话,传统的DDD⽅法不能盲目 地应用在⼀个⽆限大的领域模型中。

真正 让模型得以最大程度地扩展,并且不不必牺 牲其概念完整性的⽅法叫做“上下⽂文”。限界上下文明确地定义模型所应⽤的上下文。根据团队的组织、软件系统的各个部

分的⽤法以及物理理表现(代码和数据库模 式等)来设置模型的边界。在这些边界中 严格保持模型的⼀致性,⽽不要受到边界 之外问题的干扰和混淆。

通过定义不同上下文之间的关系,中创建的一个所有模型上下文的全局视图。

6、DDD领域设计的服务划分

6.1 修缮模式(遗留系统重构)

“修缮者模式”在既有系统资产的基础上,通过剥离新业务和功能,逐步“释放”现有系统耦合度,解决遗留系统质量不稳定和Bug多的 问题。实现传统IT性能提升,⾯对传统的IT业务更加稳定灵活,降低维护成本。

‣修缮模式适⽤于需求变更频率不高的存量系统

6.2绞杀模式(遗留系统重构)

绞杀者模式”在既有系统资产的基础上实现数字IT创新,⾯对创新的数字IT业务更加灵活。 ‣通过在新的应用中实现新特性,保持和现有系统的松耦合,仅在必要时将功能从原系统中剥离,以此逐步地替换原有系统。

目前中台对电销系统已采用绞杀模式,进行重构。

6.3 服务划分原则

依据业务限界上下⽂文边界划分

‣ 在业务层面实现了高内聚和低耦合‣ 在颗粒度上是⽐较适应刚开始做服务化架构的团队能力的

‣按照组织结构划分‣ 依照康威定律来划分服务

‣对于技术能⼒相对⽐比较成熟的团队,可以依据识别出来的聚合关系拆分 服务

在实操过程中,不不同组织也在应⽤用以下服务划分原则

‣按照变更的频率拆分‣ 可以按照系统功能中不同的变更频率来划分服务,通常

 来说,越靠近终端⽤户的特性变更频率越高,反之越低 

‣按照技术异构的边界划分‣ 按照不同的技术选型发展方向来划分系统

‣按照业务对于伸缩性或者健壮性的不同要求划分 ‣按照企业对于安全性的不同要求划分

7、DDD全景图

1、战略设计

战略设计会控制和分解战术设计的边界与粒度,战术设计则以实证角度验证领域模型的有效性、完整性与一致性,进而以演进的方式对之前的战略设计阶段进行迭代,从而形成一种螺旋式上升的迭代设计过程,如下图所示:

2战术设计

3、全景视图操作流程

两个不同阶段的设计目标是保持一致的,它们是一个连贯的过程,彼此之间又相互指导与规范,并最终保证一个有效的领域模型和一个富有表达力的实现同时演进。

8、领域模型

DDD革命性在于:领域模型准确反映了业务语言,而传统J2EE或Spring+Hibernate等事务性编程模型只关心数据,这些数据对象除了简单setter/getter方法外,没有任何业务方法,被比喻成失血模型。

那模型都有几种,他们的区别是什么? 我们该怎么选择? (题外话:各有优劣,大家需要找到自己期望的平衡点,不要盲目的使用任何一种。)

1、模型分类及特征

•失血模型:模型仅仅包含数据的定义和getter/setter方法,业务逻辑和应用逻辑都放到服务层中。这种类在Java中叫POJO,在.NET中叫POCO。

•贫血模型:贫血模型中包含了一些业务逻辑,但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中。可以看出,贫血模型中的领域对象是不依赖于持久层的。

•充血模型:充血模型中包含了所有的业务逻辑,包括依赖于持久层的业务逻辑。所以,使用充血模型的领域层是依赖于持久层,简单表示就是 UI层->服务层->领域层↔持久层。

•胀血模型:胀血模型就是把和业务逻辑不想关的其他应用逻辑(如授权、事务等)都放到领域模型中。我感觉胀血模型反而是另外一种的失血模型,因为服务层消失了,领域层干了服务层的事,到头来还是什么都没变。

2、对4种模型的理解

在基于贫血模型的传统开发模式中,Service 层包含 Service 类和 BO 类两部分,BO 是贫血模型,只包含数据,不包含具体的业务逻辑。业务逻辑集中在 Service 类中。在基于充血模型的 DDD 开发模式中,

Service 层包含 Service 类和 Domain 类两部分。Domain 就相当于贫血模型中的 BO。不过,Domain 与 BO 的区别在于它是基于充血模型开发的,既包含数据,也包含业务逻辑。而 Service 类变得非常单薄。

总结一下的话就是,基于贫血模型的传统的开发模式,重 Service 轻 BO;基于充血模型的 DDD 开发模式,轻 Service 重 Domain。

•贫血模型优缺点:

这种模型的优点: 1、各层单向依赖,结构清楚,易于实现和维护 2、设计简单易行,底层模型非常稳定 这种模型的缺点: 1、domain object的部分比较紧密依赖的持久化domain logic被分离到Service层,显得不够OO 2、Service层过于厚重

充血模型优缺点:

这种模型的优点: 1、更加符合OO的原则 2、Service层很薄,只充当Facade的角色,不和DAO打交道。 这种模型的缺点: 1、DAO和domain object形成了双向依赖,复杂的双向依赖会导致很多潜在的问题。

2、如何划分Service层逻辑和domain层逻辑是非常含混的,在实际项目中,由于设计和开发人员的水平差异,可能导致整个结构的混乱无序。 3、考虑到Service层的事务封装特性,Service层必须对所有的domain object的逻辑提供相应的事务封装方法,其结果就是Service完全重定义一遍所有的domain logic,非常烦琐,而且Service的事务化封装其意义就等于把OO的domain logic转换为过程的Service TransactionScript。该充血模型辛辛苦苦在domain层实现的OO在Service层又变成了过程式,

对于Web层程序员的角度来看,和贫血模型没有什么区别了。

1.事务我是不希望由Item管理的,而是由容器或更高一层的业务类来管理。

2.如果Item不脱离持久层的管理,如JDO的pm,那么itemDao.update(this); 是不需要的,也就是说Item是在事务过程中从数据库拿出来的,并且声明周期不超出当前事务的范围。

3.如果Item是脱离持久层,也就是在Item的生命周期超出了事务的范围,那就要必须显示调用update或attach之类的持久化方法的,这种时候就应该是按robbin所说的第2种模型来做。

胀血模型优缺点:

该模型优点: 1、简化了分层 2、也算符合OO 该模型缺点: 1、很多不是domain logic的service逻辑也被强行放入domain object ,引起了domain ojbect模型的不稳定 2、domain object暴露给web层过多的信息,可能引起意想不到的副作用。

评价:

在这四种模型当中,失血模型和胀血模型应该是不被提倡的。而贫血模型和充血模型从技术上来说,都已经是可行的了。

第一种模型绝大多数人都反对,因此反对理由我也不多讲了。但遗憾的是,我观察到的实际情形是,很多使用Hibernate的公司最后都是这种模型,

这里面有很大的原因是很多公司的技术水平没有达到这种层次,所以导致了这种贫血模型的出现。从这一点来说,Martin Fowler的批评声音不是太响了,而是太弱了,还需要再继续呐喊。

第二种模型就是Martin Fowler一直主张的模型,实际上也是我们一直在实际项目中采用这种模型。不过我觉得这种模型仍然不够完美,因为你还是需要一个业务逻辑层来封装所有的domain logic,这显得非常罗嗦,

并且业务逻辑对象的接口也不够稳定。如果不考虑业务逻辑对象的重用性的话(业务逻辑对象的可重用性也不可能好),很多人干脆就去掉了xxxManager这一层,在Web层的Action代码直接调用xxxDao,

同时容器事务管理配置到Action这一层上来。Hibernate的caveatemptor就是这样架构的一个典型应用。

第三种模型是我很反对的一种模型,这种模型下面,Domain Object和DAO形成了双向依赖关系,无法脱离框架测试,并且业务逻辑层的服务也和持久层对象的状态耦合到了一起,会造成程序的高度的复杂性,

很差的灵活性和糟糕的可维护性。也许将来技术进步导致的O/R Mapping管理下的domain object发展到足够的动态持久透明化的话,这种模型才会成为一个理想的选择。

就像O/R Mapping的流行使得第二种模型成为了可能Martin Fowler的Domain Model,或者说我们的第二种模型难道是完美无缺的吗?当然不是,接下来我就要分析一下它的不足,以及可能的解决办法。

(详细代码示例及解析请参阅:https://my.oschina.net/u/1999167/blog/1841997

3、为什么基于贫血模型的传统开发模式如此受欢迎?

前面我们讲过,基于贫血模型的传统开发模式,将数据与业务逻辑分离,违反了 OOP 的封装特性,实际上是一种面向过程的编程风格。

但是,现在几乎所有的 Web 项目,都是基于这种贫血模型的开发模式,甚至连 Java Spring 框架的官方 demo,都是按照这种开发模式来编写的。

4、 DDD 完全的充血或者胀血模型得与失

在聊到DDD的时候,我经常会做一个假设:假设你的机器内存无限大,永远不宕机,在这个前提假设下,我们是不需要持久化数据的,也就是我们可以不需要数据库,

那么你将会怎么设计你的软件?这就是我们说的Persistence Ignorance:持久化无关设计。没了数据库,领域模型就要基于程序本身来设计了,热爱设计模式的同学们可以在这里大显身手。在面向过程,面向函数,面向对象的编程语言中,面向对象无疑是领域建模最佳方式。

类与表有点像(不少人认为表和类就是对应的,行row和对象object就是对应的),我个人强烈地不认同这种等同关系,这种认知直接导致了软件设计变得没有意义。类和表有以下几个显著区别,

这些区别对领域建模的表达丰富度有显著的差别,有了封装、继承、多态,我们对领域模型的表达要生动得多,对SOLID原则的遵守也会严谨很多。

由于不再承载领域建模这个特性,数据库的设计可以变得天马行空,任何可以加速存储和搜索的手段都可以用上,我们可以用column数据库,可以用document数据库,

可以设计非常精巧的中间表去完成大数据的查询。总之数据库设计要做的事情就是尽可能的高效存取,而不是完美表达领域模型(此言论有点反动,大家看看就好),这样我们再看看架构图:

所以:理想很丰满,现实很骨感。我们并不能有无限大的内存。 在实际应用中我们一定是要避免模型的胀血。不然会带来很大的麻烦。

9、领域驱动在中台业务分析中的实践

1 、业务中台DDD领域 应用架构规范

2 、 业务中台使用DDD领域建模的愿景(架构分层)

3 、现有系统使用DDD进行领域分析

4、 数据结构模型边界的构建

个人总结:DDD只是一种方法论,网上各种公司的DDD框架,也只是对方法论按照自己的理解进行的一种实践和实验。 所以不要纠结于什么才是一个DDD框架,怎么写一个DDD框架。

更不要死板的去套DDD的各种充血贫血模型, 找到适合自己的模型,解决建模问题才是最重要的。 DDD只是为你提供了一套系统的方法论仅此而已,并没有多高大上。

推荐教程与文档:

板桥大话DDD 用大白话简单谈谈DDD的一些基础特点,只是扫盲!数据库SQL强人慎入

板桥DDD研究十年心得:《复杂软件设计之道:领域驱动设计全面解析与实战》 承蒙机械出版社厚爱

板桥:为什么DDD的Bounded Context翻译为"有界上下文"?

板桥:DDD中问题空间和解决方案空间是一个伪命题

业务代码编程陷阱案例 - jaxenter 非常普遍的不恰当的编程方式,失血模型导致的陷阱

面向对象建模与数据库建模两种分析设计方法的比较 数据库驱动设计与对象建模是决定软件不同命运的两大派别,谁可以让软件更具有生命,维护拓展更方便?伸缩性更强?

鲍勃大爷:先设计对象的行为,再设计数据库表结构! 软件工程大师、敏捷创建者之一鲍勃大叔的建议

面向对象与领域建模 据调查,目前有70%左右程序员是在使用OO语言编写传统过程化软件,缺乏完整的面向对象思维方法的教育和培训是基本根源,本文对软件开发中几个常见问题提出了独立的见解及尖锐的观点

Evans DDD 领域建模 如何提炼模型,而不是数据表,进而精化模型对象,使其能够反映领域概念基本本质是一个复杂过程,Evans DDD是2004年提出的具备革命性影响的软件思想。

实战DDD(Evans DDD:Domain-Driven Design领域驱动设计) 领域建模是一种艺术的技术,不是数学的技术,它是用来解决复杂软件快速应付变化的解决之道。

领域模型驱动设计(Evans DDD)之模型提炼

软件建模设计

如何从职责和协作中发现丰富的充血对象?失血模型贫血模型是DDD最大敌人,如何根据SOLID原则GRASP原则设计业务行为?本文给出了DDD具体实践中一些具体细节,是和DDD配合一起进行面向对象分析设计的好方法。

业务模型统一描述 统一语言是DDD一个重要特征和重点。

DDD CQRS和Event Sourcing的案例:足球比赛 DDD + CQRS + Event Sourcing实现案例,结合代码与理论讲解。

集装箱车队系统的DDD案例 为上海某大型港口公司的运输系统实施的一个领域驱动设计DDD的实战咨询案例。

DDD仓储实现:Spring Data JDBC教程

不使用DDD的后果:为什么我们停止了向微服务的迁移?

使用DDD聚合发现隐藏的业务规则的案例分析:数据库事务的业务实现

向领域驱动设计前进: 如何使用DDD实现从单体到微服务迁移打造业务平台或中台?

DDD+微服务大型案例:Uber如何从复杂的RPC微服务转向面向业务领域的微服务架构DOMA?

全球大型电商Shopify如何使用DDD实现单体架构的模块化?

更多#DDD领域驱动设计专题、领域事件专题

参考博客文献:(吃水不忘挖井人)

•浅谈 MVC、MVP 和 MVVM 架构模式:https://draveness.me/mvx

•上善若水的博客:http://deshui.wang/

•CRUD工程师晋级之路:https://zhuanlan.zhihu.com/p/25442175

•对象和数据库的天然阻抗:https://www.jdon.com/mda/oo-reltaion2.html

•Commands & Events instead of CRUD — Part 1: Commands:https://hackernoon.com/commands-events-instead-of-crud-part-1-commands-17f4c7aee33b

•汤雪华的博客:https://www.cnblogs.com/netfocus/

•There is No U in CRUD:http://jlhood.com/there-is-no-u-in-crud/

•Event sourcing vs CRUD:https://community.risingstack.com/event-sourcing-vs-crud/

•阿里盒马领域驱动设计实践:https://www.infoq.cn/article/alibaba-freshhema-ddd-practice

•DDD战略篇:架构设计的响应力:https://zhuanlan.zhihu.com/p/30878497

•使用DDD来构建你的REST API,而不是CRUD:http://blog.didispace.com/use-ddd-design-rest-api/

•DDD & co., part 1: What's wrong with CRUD:https://www.thenativeweb.io/blog/2017-10-25-09-46-ddd-and-co-part-1-whats-wrong-with-crud/

•DDD的终极大招——By Experience:https://insights.thoughtworks.cn/ddd-by-experience/

•领域驱动设计概览:http://zhangyi.xyz/overview-of-ddd/

•Refactoring from anemic model to DDD:https://blog.pragmatists.com/refactoring-from-anemic-model-to-ddd-880d3dd3d45f

•为什么DDD是设计微服务的最佳实践:https://www.jianshu.com/p/e1b32a5ee91c

•领域驱动设计在互联网业务开发中的实践:https://kb.cnblogs.com/page/586236/

•领域驱动设计(DDD:Domain-Driven Design) https://www.jdon.com/ddd.html

领域驱动设计之我见

领域驱动设计之实践与反思

#DDD案例 #DDD有界上下文 #DDD聚合

#DDD实体 #DDD值对象 #DDD服务

#DDD仓储模式 #DDD Specification规格模式

#领域事件 #EventStorming #CQRS架构

作者:京东科技 黄学斌

来源:京东云开发者社区

与【实践篇】最全的【DDD领域建模】小白学习手册(文末附资料)相似的内容:

【实践篇】最全的【DDD领域建模】小白学习手册(文末附资料)

DDD领域建模被各个大小厂商提起并应用,而每个人都有自己的理解,本文就是针对小白,系统地讲解DDD到底是什么,解决了什么问题,及一些建议和实践。本文主要是思想的一种碰撞和分享,希望能对朋友们有所启发或帮助。

关于DDD和COLA的一些总结和思考

写在前面: 其实之前一直想汇总一篇关于自己对于面向对象的思考以及实践的文章,但是苦于自己的“墨迹”,一延再延,最近机缘巧合下仔细了解了一下COLA的内容,这个想法再次被勾起,所以这次一鼓作气,准备好好梳理一篇。至于标题,因为是被DDD和COLA唤起的,索性就叫这个吧。 思维:面向对象和面向过程 领域

【实践篇】基于CAS的单点登录实践之路

上个月我负责的系统SSO升级,对接京东ERP系统,这也让我想起了之前我做过一个单点登录的项目。想来单点登录有很多实现方案,不过最主流的还是基于CAS的方案,所以我也就分享一下我的CAS实践之路。

使用Docker安装Odoo 17(非Docker Compose)

使用Docker安装Odoo 17(非Docker Compose) 前言 最近在学习Odoo,先是windows 安装企业版,多年不用windows的服务器操作系统,一看windows的ECS那么贵就想折腾一下用linux服务器来跑Odoo社区版.于是开始实践,这篇文件只记录结果。其中趟坑的滋味暂

《最新出炉》系列初窥篇-Python+Playwright自动化测试-19-处理鼠标拖拽-中篇

1.简介 上一篇中,主要是介绍了拖拽的各种方法的理论知识以及实践,今天宏哥讲解和分享一下划取字段操作。例如:需要在一堆log字符中随机划取一段文字,然后右键选择摘取功能。 2.划取字段操作 划取字段操作就是在一段文字中随机选中一段文字,或者在标记文字。当然了,这个在一些网站的登录也需要滑块验证等。

quarkus数据库篇之一:比官方demo更简单的基础操作

《quarkus数据库篇》系列的开篇,编码实战最基础的数据库增删改查,数据库用的是PostgreSQL,在官方demo基础上进一步精简,极速入门quarkus数据库操作

《一个程序猿的生命周期》-《发展篇》- 46.2000万预算的项目,为什么跟踪15个月失败了

给我们带来最直接的感受是:看似前景很美好,实质上却很卷。最应该反思和总结的是:尊重价值规律,在价值规律的原则下做事是否具备合理性,这是走的更远的基本保障,但是又很难做到。

MQ消息队列篇:三大MQ产品的必备面试种子题

MQ(Message Queue)作为一种用于实现异步通信的技术,具有重要的作用和应用场景。在面试过程中,MQ相关的问题经常被问到,因此了解MQ的用途和设计原则是必不可少的。本文总结了MQ的常见面试题,包括MQ的作用、产品选型、消息不丢失的保证、消息消费的幂等性、消息顺序的保证、消息的高效读写、分布式事务的最终一致性等方面。通过深入理解这些问题,可以更好地理解MQ的应用和设计,为面试和实际应用提供参考。

一键自动化博客发布工具,用过的人都说好(segmentfault篇)

segmentfault是我在这些平台中看过界面最为简洁的博客平台了。 今天就以segmentfault为例,讲讲在blog-auto-publishing-tools中的实现原理。 前提条件 前提条件当然是先下载 blog-auto-publishing-tools这个博客自动发布工具,地址如下:

玩转服务器之数据传输篇:如何快速搭建FTP文件共享服务器

FTP服务(File Transfer Protocol,FTP)是最早应用于主机之间数据传输的基本服务之一,是目前使用最广泛的文件传送协议。FTP文件共享服务器在日常办公中可以实现多人之间文件的传递和共享,极大提高协同办公的效率