领域事件：解耦微服务的关键 DDD分层架构：有效降低层与层之间的依赖 微服务架构模型：几种常见模型的对比和分析 中台：数字转型后到底应该共享什么？ DDD、中台和微服务：它们是如何协作的？...领域事件：解耦微服务的关键 在事件风暴（Event Storming）时，我们发现除了命令和操作等业务行为以外，还有一种非常重要的事件，这种事件发生后通常会导致进一步的业务操作，在 DDD 中这种事件被称为领域事件...举例来说的话，领域事件可以是业务流程的一个步骤，比如投保业务缴费完成后，触发投保单转保单的动作；也可能是定时批处理过程中发生的事件，比如批处理生成季缴保费通知单，触发发送缴费邮件通知操作；或者一个事件发生后触发的后续动作...通过领域事件驱动的异步化机制，可以推动业务流程和数据在各个不同微服务之间的流转，实现微服务的解耦，减轻微服务之间服务调用的压力，提升用户体验。...但项目级的微服务可能会调用其它微服务，你看在下面这张图中，比如某个项目级微服务 B 调用认证微服务 A，完成登录和权限认证。
什么是领域事件 除了命令和操作等业务行为，还有一种非常重要的事件，这种事件通常会导致进一步的业务操作，在DDD（Domain Driven Design，领域驱动设计）中，这种事件叫做 领域事件。...或者是一个事件发生后触发进一步操作， 比如，密码连续输入错误3次，账户锁定。这里的密码输入就是一个领域事件。...在你没有接触领域事件或EDA（事件驱动架构）之前，你会如何实现这个用例？肯定是简单直接的方法调用，在一个事务中分别去调用状态更新方法、扣减库存方法、发送捡货通知方法。 上面的实现有什么问题？...试想一下，若现在要求支付成功后，需要额外发送一条付款成功通知到微信公众号，我们怎么实现？想必我们需要额外定义发送微信通知的接口并封装参数，然后再添加对方法的调用。...总结 领域事件是 DDD 的重要概念，设计时需要关注领域事件，用领域事件来驱动业务流转，尽量采用事件的最终一致性，降低微服务直接的耦合，实现微服务间的解耦，维护领域模型的独立性和数据一致性。
本文作者：bryanzhao，微信支付后台开发工程师 | 导语 随着业务的不断发展，我们发现自己的系统开始变得有点臃肿，为了减少复杂性，我们尝试借助DDD来改善我们的系统。...从业务上来讲，我们的核心是通过提供业务中IoT设备上的增值运营服务 增值运营产品子域：支撑域，这里主要是我们提供增值运营产品，如电子海报、互动海报等 生效场景子域：支撑域，业务中增值运营产品有不同生效场景...这部分是业界常见问题，可以使用通用方案来解决，实际上我们也是接入TEG的能力来实现 其中我们系统中的商户信息依赖了微信支付商户账号信息和IoT设备铺设服务信息，这里使用防腐层进行隔离，将外部的商户信息“...领域事件含义很广泛，可以是业务流程的一个步骤，也可以是一个事件发生后触发的后续动作，缴费完成之后，触发短信通知；上面在设计聚合的时候，我们提到一个原则：在边界之外使用最终一致性，一次事务最多只能更改一个聚合的状态...But Most Important： 微信支付行业应用团队招聘前端、后台、数据分析工程师，在这里你可以和优秀的同事协同进化，一展所长参与到各类激动人心的业务中!
基础概念 领域 领域就是用来确定范围的，范围即边界，这也是 DDD 在设计中不断强调边界的原因。 简言之，DDD 的领域就是这个边界内要解决的业务问题域。 领域可以进一步划分为子领域。...其实很好理解，DDD 的研究方法与自然科学的研究方法类似。当人们在自然科学研究中遇到复杂问题时，通常的做法就是将问题一步一步地细分，再针对细分出来的问题域，逐个深入研究，探索和建立所有子域的知识体系。...当接收到订阅的主题数据时，事件订阅服务会调用事件处理领域服务，完成进一步的业务操作。 服务依赖 在《实现领域驱动设计》一书中，DDD 分层架构有一个重要的原则：每层只能与位于其下方的层发生耦合。...在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构。 DDD代码模型 微服务—级目录是按照DDD分层架构的分层职责来定义的。...对于一个WEB页面，小程序，微信公众号等前端需要的数据对象。也有团队用VO表示领域层中的Value Object值对象，这个要根据团队的规范来定义。
事件接收和处理 （四）具体案例分析 参考书籍、文献和资料 领域驱动实践总结一:基本理论总结与分析 领域驱动设计DDD是一种设计思想，它可以同时指导中台业务建模和微服务设计(中台本质是业务模型，微服务是业务模型的系统落地...聚合之间的服务调用和数据关联应该是尽可能的松耦合和低关联，聚合之间的服务调用应该通过上层的应用层组合实现调用，原则上不允许聚合之间直接调用领域服务。...微服务内的领域事件 当领域事件发生在微服务内的聚合之间，领域事件发生后完成事件实体构建和事件数据持久化，发布方聚合将事件发布到事件总线，订阅方接收事件数据完成后续业务操作。...微服务内应用服务，可以通过跨聚合的服务编排和组合，以服务调用的方式完成跨聚合的访问，这种方式通常应用于实时性和数据一致性要求高的场景。...领域事件发生后，事件中的业务数据不再修改，因此业务数据可以以序列化值对象的形式保存，这种存储格式在消息中间件中也比较容易解析和获取。 事件发布之前需要先构建事件实体并持久化。
图片 图片 引言 | 本文作者从微信团队维护的带货类项目所遇卡点出发，尝试用领域驱动设计方法（简称DDD），保障在快节奏、多人协作的项目迭代中，维持系统的可维护性、可拓展性、高内聚低耦合和稳定性。...作者首先剖解相关概念原理，之后代入亲身参与的微信团队实际项目、围绕DDD方法进行优化实操。...直到MartinFowler于2014年发表论文《Microservices》，引起大家对微服务的关注，至此DDD重新慢慢的回到了大众的视野中。...实践例子： 在我们的增值业务中，交易域的"支付成功"就是一个领域事件，计费域订阅这个领域事件，从而可以根据这个事件调整客户的计费资源包实体。...可以想象，如果这里没有采用领域事件， 而是交易域直接调用计费域的rpc通知交易成功，那么当后续有其他域需要接受“支付成功”这个事件，或者，计费域被调用的接口出现故障。
2、微服务代码模型 根据领域对象在 DDD 分层架构中所在的层、领域类型、与代码对象的映射关系，定义领域对象在微服务代码模型中的包、类和方法名称等，设计微服务工程的代码层级和代码结构，明确各层间的调用关系...领域类型： 在领域模型中根据 DDD 知识域定义的领域对象的类型，如：限界上下文、聚合、聚合根（实体）、实体、值对象、事件、命令、应用服务、领域服务和仓储服务等。...本栏说明领域对象需依赖的其他领域对象，如上层服务在组合和编排过程中对下层服务的调用依赖、实体之间或者实体与值对象在聚合内的依赖等。 包名： 代码模型中的包名，本栏说明领域对象所在的软件包。...在记录这些领域对象的同时，我们也会标记各对象在 DDD 中的层和对象类型等属性，如：应用服务、领域服务、事件和命令等类型。 2、领域建模：领域建模是一个收敛的过程。...两个微前端之上有一个集成主页面，可根据页面流动态加载请假和考勤的微前端页面。 步骤四：代码模型设计¶ 根据 DDD 的代码结构模型和各领域对象在所在的包、类和方法，定义出请假微服务的代码结构模型。
在单体应用或者大模块应用中，哪怕服务本身业务场景比较小，但是如果本身业务迭代速度快，服务迭代复杂度高，DDD仍然可以是一个很好的选择。...应用实现中需考虑额外的复杂性，因此DDD相比基于 CRUD 的常规应用更具意义。 领域划分心法 在领域划分上主领域进一步划分为多个子域。...从更高层次上看，架构中定义了一个 API 层、包含存储的四个模块，分别对应于所发现的四个子域，还包含一个用于通信的公共事件总线（EventBus）。...为存储要发布的事件，发件箱模式在数据存储中添加了独立的表。事件的添加，实现中通过执行任务的命令，以及等同于命令的事务。 此后，这些事件通过单独的流程，转发到另一个模块的收件箱中。...在微服务架构中，每个模块都以独立的进程运行。模块间的通信必须使用网络实现，并且通常通过同步服务 API 调用（即 RPC，远程过程调用），或是使用代理（即消息传递）实现。
首先，我们需要了解 DDD 中反复提到的“业务领域”和“业务子领域”的概念，并将“业务子域”区分出 3 个类别：核心子域、通用子域、支撑子域。 所谓的“业务领域”，指的就是“业务领域模型”。...、事件风暴图等工具（如果您不明白这些工具是啥，暂时不管它）表达出各场景下的、各情况的业务流程； 业务用例识别——在泳道图、业务服务蓝图、事件风暴图等工具表达的业务流程基础上，识别出系统将要满足的“业务用例...限界上下文映射就是搞清楚这些“限界上下文”模块之间是怎样的协作关系（调用关系、事件通知关系等等）。 “限界上下文”的划分，最重要的就是追求的“高内聚、低耦合”。...需要明确的是，按照微信支付规范，需要先在系统后台调用微信支付系统接口创建预支付流水号、然后返回给前端小程序界面提示用户进行支付密码验证（或其它验证方式）后，微信支付系统“完成支付”，并调用本系统提供的开放接口...该业务用例是供微信支付系统在用户支付成功后，反向调用本系统的接口。
目录 DDD实践：如何用DDD重构中台业务模型？ 领域建模：如何用事件风暴构建领域模型？ 代码模型（上）：如何使用DDD设计微服务代码模型？ 代码模型（下）：如何保证领域模型与代码模型的一致性？...总结成一句话就是：“分域建模型，找准基准域，划定上下文，聚合重归类。” 其它业务域重构后的中台业务模型 第三步：中台归类，根据领域模型设计微服务。 完成中台业务建模后，我们就有了下面这张图。...领域服务和应用服务都可以调用仓储服务接口，通过仓储服务实现数据持久化。2. 服务的调用 2. 服务的调用 微服务的服务调用包括三类主要场景：微服务内跨层服务调用，微服务之间服务调用和领域事件驱动。...微服务将服务发布到 API 网关，微前端调用发布在 API 网关中的服务，即完成业务单元内的前后端集成。...所有的领域都用 DDD 很多人在学会 DDD 后，可能会将其用在所有业务域，即全部使用 DDD 来设计。
微服务的定义 微服务中的“微”虽然表示服务的规模，但它并不是使应用程序成为微服务的唯一标准。当团队转向基于微服务的架构时，他们的目标是提高敏捷性，即自主且频繁地部署功能。...对这个系统建模的另一种方法是将相关模型分离或分组到单独的微服务中。在 DDD 中，这些模型（价格、定价项和折扣）被称为聚合（Aggregates）。聚合是由相关模型组成的自包含模型。...订单服务发出一个域事件（稍后会在本文中对此进行详细介绍）。支付服务监听此事件并完成订单的结算 联络中心服务可能有许多聚合，但我们只对该用例中的订单聚合感兴趣。...为调用者保留相同功能的一个选项是，让订单服务负责调用退款服务并创建一个复合响应。这种方法会引起以下几个问题： 订单服务现在与另一个服务集成，纯粹是为了支持那些需要退款数据和订单数据的调用者。...订单服务有另一个集成，因此需要考虑另一个故障点：如果退款服务出现故障，订单服务是否仍可以发送部分数据，并且调用者是否可以优雅地处理故障呢？
领域的规模 一个系统中，一个领域可以分为多个子域，子域还能分为多个子域。...但在构建领域模型时，我们并非需要把所有的领域事件都列举出来，我们常常只需要关注那些比较特殊的事件，即那种可能存在跨子域操作的事件。...而限界上下文之间的映射，则是通过微服务之间的调用；领域事件则是通过通用的消息通知服务，等等。基于如此去构建我们的后端应用，则可以按照DDD的理念，从业务出发，用微服务架构的技术去实现领域驱动的设计。...基于微前端的业务模块拆分 就像后端进行微服务拆分一样，在前端应用中，我们将业务进行拆分，从底到顶的去把一个业务模块构建出来。...这样我们就可以避免在一个EventService中写出相同的事件名，同时，其他模块使用了相同事件名，也不会影响本事件服务的执行。
| 如何在实践中应用DDD 想象一下，有这样一个场景： 一位顾客想在商家的网站上购买一件T恤，价格是10美元。 顾客可以用各种支付方式来支付这件T恤，如Visa卡或微信钱包。...将遵循以下步骤，应用DDD对基于上述场景的支付系统进行建模。 分析现实世界中的业务用例，以获得问题空间中的域和子域。通常，在这个阶段，Event Storming是一个很好的工具。...定义解决方案空间中的有界上下文 在有界限的上下文中，应用战术性DDD模式来定义实体、聚合、领域服务、领域事件等。 使用上一步的结果来确定你的团队中的微服务。 以下是分析结果。...领域服务 在我们的实践中，域服务是为一个聚合体提供的无状态业务逻辑服务，遵循单一责任模式。通常情况下，我们会在领域服务中封装领域仓库、聚合变化和领域事件发布。...在未来，我们将继续深入研究DDD模式中的每一个主题，如层管理、领域事件存储、上下文映射模式等。 ------------- END ------------- 扫描下方二维码，加入技术群。
在大多数情况下，这里不使用依赖注入，尽管事件调度程序实现可能会出现罕见的异常。领域层中的领域服务和其他业务逻辑甚至不需要真正位于接口后面，因为该逻辑不太可能随着时间而改变，并且不需要多态性。...在使用接口确实有意义的领域领域，例如使用策略模式来封装不同的业务逻辑，继续使用它们；否则，只需将域服务直接注入需要它们的类中。...这样，它本身不包含任何一流的业务逻辑，而是通过对领域层的调用来组织该逻辑。它可以协调任务并将工作委托给域，但它不包含业务规则或维护业务状态。 应用层同样使用注入的持久化接口执行持久化操作。...它们与域事件的不同之处在于可以拒绝命令；事件不能。命令通常通过应用层与域层交互。这很重要，因为域层包含所有业务逻辑并负责使系统保持一致状态。...最后，我研究过的大多数专家都同意 CQRS 可以在不使用事件溯源的情况下提供巨大的好处。这是我建议您谨慎行事的另一个领域，因为这些高级模式不适合胆小的人。
随着最近几年微服务架构已成为软件技术架构设计的事实标准，DDD重新进入业界的视野并得到广泛使用，其天然能够很好分离业务复杂度的优点使它成为微服务划分甚至业务中台架构设计的最佳方法。...识别与聚焦核心域是领域驱动设计首要原则。这是另一个层面上的分治。...中台架构终于从问题域过渡到解决方案域。 ? 基于DDD的业务中台架构推演全景图 如何实施 来到这里，理论上来说领域建模的过程就算完成了。...临门一脚 - 从限界上下文到微服务，从应用架构到技术架构 当我们遵循DDD的思路推演出业务中台的限界上下文时，我们得到的是中台的逻辑应用架构。...同样的，对领域模型的外部调用（如Restful请求或消息）也不应该直接触达领域模型，而是应该由应用层服务隔离开。这也就形成了所谓的整洁架构。 ?
应用服务 应用服务在领域服务的上层，直接对外部提供接口，相较于DDD之前的分层模型（facade-serviece-dao），DDD中的应用服务层会更薄一点，也更适应于业务变化，毕竟领域服务和实体行为相对稳定...这是因为获取聚合一般不是简单的Dao.get这种操作，通过Repositories的封装，领域服务和实体行为只需简单的调用Repositories方法就能完成聚合的存取操作，而不用关心数据存储介质。...一个限界上下文封装了一个相对独立子领域的领域模型和服务。限界上下文地图描述了各个子领域之间的集成调用关系，这个定义和微服务的划分不谋而合，以提供业务能力为导向的、自治的、独立部署单元。...说了这么多概念，下面看一下他们在DDD分层中的各自位置： ?...在DDD中，和领域事件相关的2个概念有事件溯源和CQRS等。 事件溯源并不关心当前状态，而是关注持续不断的变化事件。
领域事件可以是业务流程的一个步骤，如一个事件发生后触发的后续动作：密码连续输错三次，触发锁定账户的动作。 领域事件为何要用最终一致性，而非SOA直接调用？...在微服务内，不是说少用领域事件，而是推荐少用事件总线。DDD是以聚合为单位进行数据管理，若一次操作会修改同一微服务内的多个聚合的数据，就需保证多个聚合的数据一致性。...跨微服务事件可推动业务流程或数据在不同子域或微服务间直接流转。 跨微服务的事件机制要总体考虑事件构建、发布和订阅、事件数据持久化、MQ，甚至事件数据持久化时还可能需考虑引入分布式事务。...领域事件发生后，事件中的业务数据不再修改，因此业务数据可以以序列化值对象的形式保存，这种存储格式在消息中间件中也比较容易解析和获取。 为保证事件结构的统一，通常创建事件的基类，子类可自行继承扩展。...领域事件驱动机制可实现一个发布方N个订阅方的模式，这在传统的直接服务调用设计中基本是不可能做到的。 领域事件 V.S CQRS CQRS主要是想读写分离，将没有领域模型的查询功能，从命令中分离出来。
由于领域事件需要发布到外部系统，比如发布到另一个限界上下文。由于这样的事件由订阅方处理，它将对本地和远程上下文产生深远的影响。 那领域事件为什么要用最终一致性，而不是传统SOA的直接调用？...在微服务内，不是说少用领域事件，而是推荐少用事件总线。DDD是以聚合为单位进行数据管理，若一次操作会修改同一微服务内的多个聚合的数据，就需保证多个聚合的数据一致性。...跨微服务事件可推动业务流程或数据在不同子域或微服务间直接流转。 跨微服务的事件机制要总体考虑事件构建、发布和订阅、事件数据持久化、MQ，甚至事件数据持久化时还可能需考虑引入分布式事务。...领域事件发生后，事件中的业务数据不再修改，因此业务数据可以以序列化值对象的形式保存，这种存储格式在消息中间件中也比较容易解析和获取。 为保证事件结构的统一，通常创建事件的基类，子类可自行继承扩展。...领域事件驱动机制可实现一个发布方N个订阅方的模式，这在传统的直接服务调用设计中基本是不可能做到的。 领域事件 V.S CQRS CQRS主要是想读写分离，将没有领域模型的查询功能，从命令中分离出来。
从业务视角建立 DDD 与中台的统一语言 在了解了中台和 DDD 的问题域分解和建模的过程后，我们就可以从业务视角来建立 DDD 与中台的统一语言了。...小结 我们对 DDD 与中台和微服务的关系做一个小结，如下图所示。 ? DDD 与中台和微服务的关系是：“中台本质是领域中的某一个子域，需要抽象并标准化，按照单一职责原则建立可复用的领域模型。...中台和微服务整体设计过程 一般来说，对于比较小的领域我们可以直接从事件风暴开始，完成领域建模。而对于企业级中台而言，由于企业领域非常庞大，不适合直接开展事件风暴。...为了避免聚合之间产生服务依赖，聚合之间的数据交互一般采用异步化的领域事件驱动方式。另外，你也可以将聚合之间的服务调用上升到应用层，在应用服务中完成不同聚合之间的服务组合和调用。...比如，在中台建设时：微前端设计、领域事件驱动模型以及单元化的设计思想等内容，无法在这里一一展开。 你可以参考《中台架构与实现：基于 DDD 和微服务》，里面有非常详细的介绍。
如何在实践中应用DDD 问题空间 解决方案空间 从领域模型到微服务 结论 ---- 在Airwallex，领域驱动设计（DDD）方法被用来指导如何对复杂的业务问题和系统设计进行建模。...将遵循以下步骤，应用DDD对基于上述场景的支付系统进行建模。 分析现实世界中的业务用例，以获得问题空间中的域和子域。通常，在这个阶段，Event Storming是一个很好的工具。...定义解决方案空间中的有界上下文 在有界限的上下文中，应用战术性DDD模式来定义实体、聚合、领域服务、领域事件等。 使用上一步的结果来确定你的团队中的微服务。 以下是分析结果。...领域服务 在我们的实践中，域服务是为一个聚合体提供的无状态业务逻辑服务，遵循单一责任模式。通常情况下，我们会在领域服务中封装领域仓库、聚合变化和领域事件发布。...在未来，我们将继续深入研究DDD模式中的每一个主题，如层管理、领域事件存储、上下文映射模式等。 ---- ---- 欢迎加入我的知识星球，一起探讨架构，交流源码。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
