本文介绍了DDD（领域驱动设计）的落地实践，包括业务分析、战略设计和战术设计三个阶段。战略设计涉及事件风暴、业务分析和领域建模，旨在构建领域模型和限界上下文。战术设计则关注微服务的领域对象分析、边界划分及结构分层，实现领域模型在代码中的映射。文章强调了值对象、实体、聚合和聚合根等概念，并以物流业务为例阐述了如何进行领域建模。
引言
通过前面的文章介绍，相信大家对于什么是 DDD 有了初步的了解，知道它是一种微服务的架构设计方法论，为我们解决如何建立领域模型，如何实现微服务划分等问题提供了方向和指导。但是对于如何具体落地使用 DDD，可能大家还是一脸懵 B 的状态，因此从本文开始以及后面的文章将对如何进行 DDD 落地进行详细的阐述。在这其中还是会涉及到 DDD 中的一些重要概念，原本想着在一篇文章中介绍所有的概念，但是我觉得，概念总是在它该出现的时候出现才会让大家印象深刻，否则这些概念只是死板的概念，我们不清楚他为什么出现以及可以解决什么问题。
DDD 大致实现过程
如下图所示，实现 DDD 落地大致需要经历这样三个阶段，即为业务分析-》战略设计-》战术设计，不同阶段的输出都是下一阶段的输入。业务分析阶段为战略设计输出经过统一语言描述的业务事件、业务逻辑以及业务分类，而战略设计阶段又为战术设计阶段输入领域模型以及边界上下文，方便其进行微服务拆分以及模型映射。下面我们分别看下这三个阶段到底都做了什么事情。
业务分析：在这个阶段需要集齐项目团队的成员主要包括领域专家、设计人员、开发人员等一起对业务问题域以及业务期望进行全面的梳理，厘请业务中的统一语言，在业务领域中发现领域事件、领域对象及其对应的领域行为，搞清楚他们各自的关联关系。
战略设计：通过 DDD 的理论，对业务进行领域划分构建领域模型，梳理出相应的限界上下文，通过统一的领域语言从战略层面进行领域划分以及构建领域模型。在构建领域模型的过程中需要梳理出对应的聚合、实体、以及对象。
战术设计：以领域模型为战术设计的输入，以限界上下文作为微服务划分的边界进行微服务拆分，在每个微服务中进行领域分层，实现领域模型对于代码的映射，从而实现 DDD 这才真正落地实施。
相关概念补充
在介绍战略设计和战术设计之前，我们先来弄清楚一些晦涩难懂的概念性的内容，这些概念看上去总是不明觉厉。我觉得 DDD 不容易入门的一个原因就是这些概念太不好理解了，即便是《领域驱动设计：软件核心复杂性应对之道》原著中的描述更加让人难以捉摸。要想理解这些概念性的内容，我们要思考为什么有这样的概念，以及它的出现是为了解决什么问题，在实际的上下文场景下是怎么运用的，我想只有这样我们对这些不明觉厉的东东才能有更加深刻的理解。我尽量结合一些实例来进行说明，方便大家的理解。
1、值对象
值对象看上去又是比较抽象的概念，越抽象的概念我们越要抓住最主要的脉络，
最低0.47元/天 解锁文章
1089
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
