本文探讨了DDD（领域驱动设计）的核心概念，包括领域模型、领域发现、事件风暴和四色建模法。文章强调了DDD在解决复杂性问题上的作用，适合在项目初期采用以支持微服务和领域驱动的架构。通过案例分析，阐述了如何通过事件风暴和四色建模法来梳理业务，以及领域模型的构建步骤。此外，还介绍了CQRS、Event Sourcing等架构设计模式，帮助读者理解如何在实践中落地DDD。
前几年就开始接触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。它能够帮助开发人员梳理核心的业务对象，从某种程度上来说就是就是领域对象中的聚合。
描述产品愿景
产品愿景的主要目的是对产品顶层价值的设计，使产品目标用户、核心价值、差异化竞争点等信息达成一
最低0.47元/天 解锁文章
571
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
