DDD战略设计相关核心概念的理解.docxVIP

DDD战略设计相关核心概念的理解 2021-12-11 01 前言 本文想再争辩一下关于领域、业务、业务模型、处理方案、BC、领域模型、微服务这些概念的含义和关系。 初衷是我发觉现在DDD领域建模以及处理方案落地过程中，经常对这些概念理解不清楚或者有歧义，导致我们不晓得如何运用这些概念来落地我们的软件。 先通过一个图来说明一下这些概念之间的关系，如下图所示 02 领域、业务、业务模型 ·?领域，即问题域、问题空间，领域是一种边界、范围。所以，一个领域代表了一个问题域的边界，也可以理解为是一个业务的边界。 ·?领域边界越大，业务范围就越大，反之则相反。通常我们大家沟通都比较宠爱用业务这一词，比如这块业务，那块业务，业务的边界，我是一个业务开发人员（区分于我是一个两头件开发人员）。而领域一词，相对比较笼统，不是那么简约懂。 ·?领域既然是一个边界，所以可以划分领域的大小。即领域划分，划分出来的子领域简称子域，每个子域对应一个小的问题域和和小的业务；当然，不同的子域的重要性也是不同的，所以才有了核心子域、支撑子域的说法，这点显而易见。 ·?每个业务都有一个对应的业务模型（留意这个业务模型不是领域模型，而是一个业务概念的模型，领域模型下面会提到），这个业务模型设计的时候，完全不需要考虑任何软件设计的思想，比如对象的笼统、承继、存储、功能，等。 我们是从业务本身动身，分析业务边界范围内的各种业务概念，以及业务概念之间的关系，通常我们可以使用一个业务模型的图来表达这些业务概念以及业务概念之间的关系。 那么如何得到一个业务模型呢？ 最常见的出名词动词描述词分析法，还有比如四色原型分析法，都可以。找一个适合本人的就行；业务模型本身格外有价值，它提炼了领域内业务的核心概念及其关系，可以挂念我们更好的理解业务本身。 03 处理方案 ·?什么是处理方案？ 我们在进行DDD领域驱动设计的实践时，会进行需求分析、领域划分、领域建模等工作。而我们的系统要落地，则需要有一套处理方案。 例如，我们要实现一个电商平台，需要一个简单的系统处理方案，但是假如这个处理方案过大，各模块、组件都揉在一起，那么就不利于整个系统的维护、演进、伸缩，等。 所以，我们需要把处理方案拆分为一个个独立的小的处理方案；所以，我们可以发觉，领域和处理方案，是两个完全不同的概念，领域代表问题空间，处理方案代表处理方案空间。 ·?处理方案该如何拆分呢？ 简约的回答是：看情况，凭阅历。说的具体点，就是我们需要使用软件设计的各种准绳、最佳实践、设计模式、非功能特性的需求，以及团队成员的情况来指点我们进行处理方案的拆分或者直接不拆分，最终得出一个综合考虑后的拆分结果。 所以，我们发觉处理方案的拆分的维度可能有很多，没有一个单一的在任何情况下都合理的切分维度。有时我们可能从功能的角度来拆分，有时从不同架构分开演进（如CQRS架构）的角度，有时从分开伸缩的角度，有时从切合团队组织架构的维度。但是拆分的时候，多考虑一些各个因素，才能让我们更好的进行处理方案空间的拆分。 04 ?BC · BC，即Bounded Context，中文翻译为限界上下文。 BC在DDD一书中初次消灭，BC的理解分为两个层面： （1）Bounded，表示边界的意思； （2）Context，即上下文，我理解为是一个场景的上下文，这个场景不局限于一般的业务场景，而是各种上下文都涵盖在内，是一个时空感知的概念。 比如我们两个人在公司交谈时的上下文是一个上下文，但是在路上交谈时，则切换到另一个上下文了，由于交谈的地点发生了变化；所以，BC合起来理解，就是一个上下文的边界。 · BC有什么用呢？ 就是为了表达上面引见的某个粒度的处理方案的上下文边界。 那为何要强调这个边界呢？ 有了这个边界，我们才可以定义这个边界内的领域模型中全部对象概念的明确含义。假如没有这个上下文边界，对同一概念在不同上下文的理解，大家就会产生偏差。 举个例子：商品，在商品中心的处理方案BC中，商品中心担任管理电商平台的全部商品，所以商品在商品中心BC中，是一个聚合根；但是在订单中心处理方案BC中，虽然也叫商品，但是它只是一个值对象。 我们晓得订单中心的订单是一个聚合，订单内聚合了多条订单明细，每个明细是一个实体，每个订单明细对应了一个商品。虽然叫做商品，但是这个商品本质上只是商品中心的商品的一部分信息，如商品ID、标题、价格，且是只读的。甚至更为常见的，叫同一个名称的对象，在不同的BC中，是属性完全不一样的不同的对象。 ·?那为何处理方案的边界要叫做BC呢？ 对，我们可以不用叫做BC，比如你就叫做处理方案边界，也没问题。只是Eric在写作DDD这本书时，把他叫做BC，所以我们沿用了他的概念。我们次要的目的是为了用BC来表达处理方案空间的边界。 · B