上周，我们通过这篇文章《为什么catch了异常，但事务还是回滚了？》来解释了，之前test4为什么会回滚的原因。 但还是收到了很多没有理解的反馈，主要是根据前文给出的线索去跟踪，是获得到了回滚的标示和异常，而让大家不理解的是，javax.validation.ConstraintViolationException异常不是最后也向外抛出了，那么为什么test4里catch没有能够捕获到呢？ 其实这个问题并不难解释，下面就通过这篇文章，做个小实验，帮助大家进一步理解大家的这个疑问！ 如果你还不了解这篇文章在讨论什么，建议先看之前的两篇： 《我来出个题：这个事务会不会回滚？》 《为什么catch了异常，但事务还是回滚了？》 动手尝试一下由于@Transactional注解的事务是通过切面来实现的，所以要通过源码去了解整个过程，可能还是不容易理解。 所以，这里教大家一个简单方法来理解这...

前几天我发了这篇文章《我来出个题：这个事务会不会回滚？》 得到了很多不错的反馈，也有不少读者通过微信、群或者邮件的方式，给了我一些关于test4的回复。其中还有直接发给我测试案例，来证明我的答案是错的。 今天，我们就来一起看看test4这个争议很大的问题。如果您是刚打开这篇文章，不了解我们在讨论啥，那可以先点击查看之前的这篇《我来出个题：这个事务会不会回滚？》。 通过这两篇文章的解析，相信你会对Spring Data JPA下的事务执行机制有质的飞跃。 为什么没回滚先来说说，那些写了代码验证“不会回滚”的情况，把这些错误答案的原因先说清楚，然后再细说test4会回滚的情况。 根据这两天读者给我的案例或者描述清楚的一些情况，归结了一下，大家写的验证代码之所以不会回滚，主要有以下三个原因： 没有按照我题目开头说的，采用InnoDB存储引擎，用了MyISAM，不支持事务，自然不会复现。 ...

下面这个问题源于前几日在我们的Spring技术交流群里，一个群友提出的关于事务回滚的疑问。 在讨论过程中，我尝试去复现群友提出的问题场景，发现了另外一个可能让大家会迷惑的情况。 当时在群里说了结果和原因，但微信群范围有限，所以单独写篇文章，拿出来给大家看看，顺便考考大家，对这块是否了解。 问题描述这个问题的基础工程我用了之前Spring Boot 2.x基础教程中《使用Spring Data JPA访问MySQL》的案例。 你可以通过下面仓库中的chapter3-10目录获取基础工程： Github：https://github.com/dyc87112/SpringBoot-Learning/ Gitee：https://gitee.com/didispace/SpringBoot-Learning/ 在这个工程中，定义一个名为User的实体： @Entity@Data@NoA...

上集我们阐述了使用微服务体系架构的关键障碍是领域模型，事务和查询，这三个障碍似乎和功能拆分具有天然的对抗。只要功能拆分了，就涉及这三个难题。 然后我们向你展示了一种解决方案就是将每个服务的业务逻辑实现为一组DDD聚合。然后每个事务只能更新或创建一个单独的聚合。然后通过事件来维护聚合（和服务）之间的数据一致性。 在本集中，我们将会向你介绍使用事件的时候遇到了一个新的问题，就是怎么样通过原子方式更新聚合和发布事件。然后会展示如何使用事件源来解决这个问题，事件源是一种以事件为中心的业务逻辑设计和持久化的方法。之后，我们会阐述微服务架构下的查询困难的问题。然后向你介绍一种称为命令查询责任分离（CQRS）的方法来实现可扩展和高性能的查询。 可靠地更新状态和发布事件从表面上看，使用事件来保持聚合之间的一致性似乎很简单。 当一个服务创建或更新数据库的一个聚合时，它只是简单地发布一个事件。但是，这只...

微服务架构变得越来越流行了。它是模块化的一种方法。它把一整块应用拆分成一个个服务。它让团队在开发大型复杂的应用时更快地交付出高质量的软件。团队成员们可以轻松地接受到新技术，因为他们可以使用最新且推荐的技术栈来实现各自的服务。微服务架构也通过让每个服务都被部署在最佳状态的硬件上而改善了应用的扩展性。 但微服务不是万能的。特别是在 领域模型、事务以及查询这几个地方，似乎总是不能适应拆分。或者说这几块也是微服务需要专门处理的地方，相对于过去的单体架构。 在这篇文章中，我会描述一种开发微服务的方法，这个方法可以解决这些问题。主要是通过领域模型设计，也就是DDD以及事件源（Event Sourcing）以及CQRS。让我们首先来看看开发人员在开发微服务的时候会遇到哪些问题吧。 微服务开发过程中的挑战模块化在开发大型复杂的应用的时候是非常有必要的。 现在许多应用大到一个人根本无法完成。而且复杂到...