带你入门领域驱动设计(DDD)
要讲DDD,不得不先说一下微服务,因为2004年由Eric Evans提出的DDD就是伴随微服务的兴起才被人们重视起来的。
微服务是一种架构,它将传统的单体架构进行拆分,使系统可以分而治之、相互解耦。我们享受微服务带来的便利的同时,也不得不直面随之而来的困惑。比如,如何拆分服务?微服务架构理论工具大都从技术角度考虑,比如服务间调用、分布式、系统运维等。当业务需求迭代的时候,却不能很好地支撑,甚至造成一个简单需求需要改动许多微服务的情况。有没有一套可以指导我们微服务拆分和代码落地的理论?答案就是我们要介绍的DDD。
一、DDD的战略模式
如果把构建一套系统比喻成打仗,那我们首先要考虑的是制定作战计划,需要把各方面的专家召集到一起,共同讨论如何作战,比如我们需要分为海陆空几方面来作战,比如哪个高地是我们重点攻击对象,这就是DDD中的战略模式。
对应到软件系统架构,我们需要首先将系统划分成多个领域,然后聚焦到核心领域,也就是DDD中说的核心域,剩下非核心的领域我们称为通用域和支撑域,通用域一般可以通过采购业界现有的系统来实现,支撑域则可以采用一般架构来实现。
确定了核心域,我们需要和该领域的专家一同分析业务需求、用户故事,找出中间的关键事件(事件:领域专家关心的,在业务上真实发生的事情,例如:客户订单已提交;账户已锁定),这一过程在DDD中被称为“事件风暴”。下一步,分析出这些关键事件的发起者、动作(什么活动产生了事件,事件是业务的输出,命令是业务的输入,例如:提交客户订单