前几年就开始接触DDD(Domain Driven Design,领域驱动设计),并且着迷于此。它更多地在战略层指导了我的设计,对于战术层面的设计,目前业界没有统一的标准,也没有特别流行的方案。虽然也有许多技术大牛们热衷于DDD,但一到代码落地便一地鸡毛,造不出“银弹”。
那DDD到底是什么呢?有什么技术落地方案呢?今天我来给大家科普一下。
基本概念
过去系统分析和系统设计都是分离的,正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样,这样割裂的结果导致,需求分析的结果无法直接进行设计编程,而能够进行编程运行的代码却扭曲需求,导致客户运行软件后才发现很多功能不是自己想要的,而且软件不能快速跟随需求变化。
DDD则打破了这种隔阂,提出了领域模型概念,统一了分析和设计编程,使得软件能够更灵活快速跟随需求变化。
DDD专门为解决复杂性而诞生,因此解决思路完全不同于传统的CRUD,但是DDD本身掌握起来并不会感觉复杂,从程序员角度看,DDD其实是研究将包含业务逻辑的ifelse语句放在哪里的学问。
Q:DDD有什么作用?
A:想想我们做软件设计的初衷是什么?通过微服务与领域驱动设计,简化设计,降低维护成本,提高软件交付速度。这要求我们落地的时候,架设一个支持微服务、支持领域驱动的架构。
Q:DDD适用于什么场景?
A:在Evans写的《领域驱动设计》一书,副标题已经说明一切:软件核心复杂性应对之道。领域驱动的真正作用,在于项目中对日后的维护,当系统变得越来越复杂的时候,才能体现出它的威力。
那新项目该不该用领域驱动?新项目并不复杂,产品还在跑模式的阶段,虽然它的优势并不能真正发挥出来,但我认为,DDD同样适用新项目。项目只会越做越复杂,我们从一开始就应该考虑日渐发胖的代码、随时可能独立的子业务。而新项目更多的是指导战略层设计(如领域建模),战术层的技术落地还是以团队成员最熟悉的方式进行,目标是持续快速交付、降低维护成本。
领域建模
Q:什么是领域模型?
A:为解决场景下的问题而形成的一套模型,然后使用这套模型来解决业务问题。 根据重复劳动经验我们会形成一套模式,领域模型也一样会形成一套模式,包括:实体、值对象、模块、领域服务。
领域发现
那领域模型是怎么一步一步确定下来的呢?推荐两种比较常用的领域发现方法:事件风暴与四色建模法。
一、事件风暴
Event Storming(事件风暴)是一种轻量级的系统分析方法,基于 DDD 的概念,能够为我们梳理系统中的各种相关元素,其中包括了核心的 Aggregate。它能够帮助开发人员梳理核心的业务对象,从某种程度上来说就是就是领域对象中的聚合。
描述产品愿景
产品愿景的主要目的是对产品顶层价值的设计,使产品目标用户、核心价值、差异化竞争点等信息达成一致,避免产品偏离方向。
产品愿景的参与角色:领域专家、业务需求方、产品经理、项目经理和开发经