在微服务架构中应用领域驱动设计原则

每天?分享?最新?软件?开发?,Devops,敏捷?,测试?以及?项目?管理?最新?,最热门?的?文章?,每天?花?3分钟?学习?何乐而不为?,希望?大家?点赞?,加?关注?,你的?支持?是我?最大?的?动力?。
微服务是开发软件的最可扩展的方式。但是,您需要一个良好的设计,让开发人员团队能够自主地工作并进行部署,而不会彼此干扰; 否则,您将失去大部分可伸缩性好处。

什么是领域驱动设计?

领域驱动设计(DDD)是一种软件设计方法,开发人员可以通过构建模型来理解域的业务需求。这些模型作为开发软件的概念基础。

知识、影响力或活动的范围。用户应用程序的主题领域是软件的领域。

一个人解决问题的能力取决于他理解这个领域的能力。开发人员是聪明人,但他们不可能是所有领域的专家。他们需要与领域专家合作,以确保代码符合业务规则和客户需求。

开发人员和领域专家使用统一的语言来共享知识、文档、计划和代码

微服务体系结构中最重要的两个 DDD 概念是有界上下文和上下文映射。

有界语境(BC)

单词出现的位置决定了它的意思。根据上下文的不同,“ book”可能指的是书面作品,也可能指的是“预订房间”有界上下文(BC)是一个术语具有明确和明确含义的空间。

在 DDD 之前,通常的做法是尝试找到一个跨越整个领域的模型。问题是,领域越大,就越难找到一致和统一的模型。DDD 的解决方案是识别 BC,这样就可以将域划分为可管理的子域。

“书”的相关属性随着上下文的变化而变化

在软件方面,我们需要精确。这就是为什么定义 BC 是至关重要的: 它为我们提供了一个精确的词汇表,称为无处不在的语言,可以在开发人员和领域专家之间的对话中使用。无处不在的语言存在于整个设计过程、项目文档和代码中。

背景图

BC 的存在预示着对通信通道的需要。例如,如果我们在一个电子商务领域工作,销售人员应该在销售产品之前检查库存。一旦销售出去,就要靠运输来确保产品送到正确的地址。在 DDD 中,这些关系以上下文映射的形式描述。

有限上下文通信用于完成高级任务

微型服务领域驱动设计

DDD 分两个阶段进行:

  1. 在战略阶段,我们确定 BC 并在上下文映射中将它们映射出来。
  2. 在战术阶段,我们根据子域的业务规则对每个 BC 建模。

让我们看看每个阶段如何在微服务体系结构设计中发挥作用。

策略性阶段

在此阶段,我们邀请开发人员、领域专家、产品所有者和业务分析人员进行头脑风暴,分享知识并制定初步计划。在促进者的帮助下,这可以采用事件风暴研讨会的形式,在这里我们构建模型并从域中的重要事件开始识别业务需求。

在事件风暴会话中,域事件被用作共享知识和确定业务需求的催化剂

在战略 DDD 中,我们采用高层次、自上而下的方法进行设计。我们首先分析域,以确定其业务规则。由此,我们得到一个 BC 列表。

策略性领域驱动设计有助我们确定个别微型服务的逻辑界限

边界起到天然屏障的作用,保护里面的模型。因此,每个 BC 代表了实现至少一个微服务的机会。

  • 开放主机服务(OHS) : 服务提供者定义一个开放协议供其他人使用。这是一种开放式关系,因为遵守协议取决于使用者。
  • 发布语言(Published Language,PL) : 这种关系使用一种众所周知的语言,比如 XML、 JSON、 GraphQL 或其他适合该领域的语言。这种关系可以与 OHS 相结合。
  • 反腐败层(Anti-orrupt Layer,ACL) : 这是服务使用者的防御机制。反腐败层是在下游服务之前实现的抽象和翻译包装层。当上游发生变化时,使用者服务只需要更新 ACL。
  • 单独的方法: 如果进一步分析发现两个服务之间的集成没有什么价值,就会发生这种情况。这是关系的对立面ーー这意味着 BC 们没有联系,也不需要互动。
  • 在战略 DDD 分析的最后,我们得到了一个详细描述 BC 及其关系的上下文映射。

    ACL 在下游实施,以减轻上游变更的影响。职业安全与健康管理局却恰恰相反。它在上游实现,为下游服务提供稳定的接口

    战术阶段

    在这个阶段,我们深入研究子域并创建模型。

    领域驱动设计是迭代的

    虽然在开始编写代码之前,我们似乎必须首先编写一个关于领域的详尽描述,但实际上 DDD 和所有软件设计一样,是一个迭代过程。

    在纸面上,有界上下文和上下文映射可能看起来不错,但是当它们被实现时,它们可能会转化为太大而不能被正确地称为微服务的服务。相反,职责重叠的多话微服务可能需要合并到一个服务中。

    随着开发的进展,您对该领域有了更好的理解,您将能够做出更好的判断,增强模型,并更有效地进行交流。

    设计微服务的更多方法

    DDD 毫无疑问是一种重理论的设计模式。因此,只有当正在开发的系统足够复杂以至于需要进行额外的规划工作时,才建议使用这种方法。

    其他方法,如测试驱动开发(tDD)或行为驱动开发(bDD) ,对于更小、更简单的系统可能就足够了。TDD 是最快的开始,并且在处理单个微服务或甚至只包含少数服务的应用程序时工作得最好。

    在更大的范围内,我们可以使用 BDD,它迫使我们通过集成和验收测试来验证整体行为。如果您从事低复杂度到中等复杂度的设计,那么 BDD 可能工作得很好,但是一旦您达到一定的阈值,维护测试可能会降低您的速度。

    您还可以结合这三种模式,为每个开发阶段选择最佳的模式,例如:

    1. 识别微服务及其与战略 DDD 的关系。
    2. 使用战术 DDD 对每个微服务进行建模。
    3. 由于每个团队都是自治的,他们可以选择采用 BDD 或 TDD (或两者的混合)来开发微服务或微服务集群。

    DDD 在学习和实现时可能会让人望而生畏,但是它对于开发微服务体系结构的价值是非常值得付出努力的。

    声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

    上一篇 2022年5月28日
    下一篇 2022年5月28日

    相关推荐