DDD从小白到入门

DDD进阶篇一

领域事件：解耦微服务的关键

1、领域事件可以是业务流程的一个步骤，比如投保业务缴费完成后，触发投保单转保单的动作也可能是定时批处理过程中发生的事件，比如批处理生成季缴保费通知单或是一个事件发生后触发的后续动作，比如密码连续输错三次，触发锁定账户的动作。在领域模型映射到微服务系统架构时，领域事件可以解耦微服务，微服务之间的数据不必要求强一致性，而是基于事件的最终一致性。
2、微服务内的领域事件：微服务内大部分事件的集成，都发生在同一个进程内，进程自身可以很好地控制事务，但一个事件如果同时更新多个聚合，需要考虑引入事件总线，但可能会增加开发的复杂度。对于实时性和数据一致性要求高的场景，会用到分布式事务，以保证发布方和订阅方的数据同时更新成功。
3、微服务之间的领域事件：跨微服务的领域事件会在不同的限界上下文或领域模型之间实现业务协作，其主要目的是实现微服务解耦，减轻微服务之间实时服务访问的压力。跨微服务的数据同时变更需要引入分布式事务，以确保数据的一致性。分布式事务机制会影响系统性能，增加微服务之间的耦合，所以要尽量避免使用分布式事务。

领域事件处理包括以下几点：
			
			事件构建和发布：事件基本属性至少包括：事件唯一标识、发生时间、事件类型和事件源、业务属性（记录事件发生那一刻的业务数据）
					事件发布之前需要先构建事件实体并持久化。事件发布方式有很多，
					可以通过应用服务或者领域服务发布到事件总线或者消息中间件，
					也可以从事件表中利用定时程序或数据库日志捕获技术获取增量事件数据，发布到消息中间件
			
			事件数据持久化：数据持久化有两种方案：
					1、持久化到本地业务数据库的表中，利用本地事务保证业务和事件数据的一致性
					2、持久化到共享的事件数据库中，因为业务数据库和事件数据库不在同一个库中，
					他们的数据持久化会跨数据库，需要使用分布式事务机制来保证业务和事件数据的强一致性。
			
			事件总线：实现微服务内聚合之间领域事件的重要组件，它提供事件分发和接收等服务。
				事件总线是进程内模型，它会在微服务内聚合之间遍历订阅者列表，采取同步或异步的模式传递数据。
			
			消息中间件：跨微服务的领域事件大多会用到消息中间件，实现跨微服务的事件发布和订阅。
			
			事件接收和处理：微服务订阅方在应用层采取监听机制，接收消息队列中的事件数据，完成事件数据的持久化后，就可以开始进一步的业务处理。

本篇文章介绍了领域事件和领域事件的处理过程，虽然偏理论但可以结合企业的具体项目或者需求文档来理解，下次将会介绍DDD的四层架构和微服务常见的架构模型。