DDD实战之五:战略设计之上下文映射和系统分层架构(上)

简介: DDD实战之五:战略设计之上下文映射和系统分层架构(上)

在完成了限界上下文的识别(也就是系统“最粗粒度”的模块划分)后,我们需要对这些上下文之间的协作关系进行分析——即“限界上下文关系映射”。也只有在完成上下文关系映射后,我们才能真正的判定自己所做出的“限界上下文识别”是否真的达到了自己想要的“低耦合、高内聚”的目标。因为,通过“限界上下文映射”我们就能够看到:

  • 这些上下文之间有哪些协作关系?
  • 这些关系是强关联还是弱关联?

关于“限界上下文识别”和“限界上下文关系映射”,我认为这是 DDD 战略设计中最重要的部分,甚至可以说:这两个工作将决定了微服务切分是否有效的关键因素!

但是,肯定会有人说:限界上下文不用 DDD,我凭直觉就能识别出来。我的回答是:是的,你貌似可以!但更重要的是限界上下文的关系映射,这将决定做微服务拆分后、这些微服务之间是怎样做到“高内聚、低耦合”的。如果你不用 DDD 战略设计,我可以很负责任的告诉你:你将来的“微服务”之间的调用关系一定会变得无法控制!

在我实际工作中接触的某大型国企 IT 系统中,所谓业务中台上千万行代码,部署在十多个微服务中心,而 80%以上的外围接口调用、或前端界面服务请求,都要从十个以上的微服务中心全部走一遍!这是不是很可怕的灾难?系统的高可用性、业务需求的快速响应还有什么保障可言?

所以说:掌握好 DDD 战略设计,几乎是做好微服务设计必不可少的前提!不懂得 DDD,你做的“微服务拆分”可能还不如不拆分,单体应用可能更适合你!

在本节内容中,除了搞定限界上下文的映射之外,我还将对系统分层架构进行设计,并在最终给出项目组可直接用于开发的代码框架结构。

需要特别说明的是:在写到这篇的过程中,我反复和多位业界大拿请教,大家普遍认为我前面第三篇中业务子域的分类上“核心子域”太多了。我经过再三考虑,将“核心子域”进行了调整,这将影响到本篇关于系统分层结构的设计,您可以跳回到第三篇重新看下“业务子域识别与分类”这一小段。这里再次重申下:您在阅读中发现我的任何不妥之处 ,可随时与我交流,我发现不妥之处一定认真思考改进,感谢您的支持!

01限界上下文映射


1跨上下文用例识别

为了识别限界上下文之间的映射关系,我们需要对跨上下文的业务用例(也叫业务服务),从架构设计的技术视角绘制服务序列图,进而识别它们之间的映射关系。

首先,第一步,我们识别出所有的跨限界上下文的业务用例。在识别某个业务用例是否跨限界上下文时,一定要注意两个基本事实:1)其实大部分业务用例都是从“群买菜”小程序前端界面发起的,前端与服务端的交互,不算跨限界上下文;2)限界上下文提供的是服务端的业务服务,跨限界上下文一定要是服务端逻辑的相互关系。

关于如何识别“服务端的跨限界上下文”业务逻辑,我认为需要逐个分析前面罗列的所有业务用例,从如下两个角度筛选:

初步分析业务用例内部的逻辑,看是否需要多个上下文来承担职责。如果是,则需将该用例纳入分析范围;

分析业务用例图中的被包含的“子用例”,看是否存在上下文包含了被归类到别的上下文的情况。如果是,则需将该用例纳入分析范围;为此,识别结果如下图罗列:

image.png

需要说明的是:有几个用例看起来好像是跨上下文的,其实不是。分别说明如下:

1. “确认购买并付款”、“创建订单预支付”、“完成订单支付”、“补收客户货款”、“退客户货款”,这几个用例其实是订单上下文和支付系统之间的关系。考虑到我们的系统上下文设计,支付系统其实不是我们目标系统的工作范围,故这里不纳入范围。

2. “后台查询店铺商品”、“后台浏览店铺订单列表”、“管理店铺客户信息”、“管理店铺员工”、“开通店铺加盟并设置分成政策”、“添加品牌店铺到加盟列表”,看起来每个用例的名称上都涉及到 2 个限界上下文、并都跟“店铺”上下文发生关系,其实它们只是需要店铺 ID,并没有与店铺上下文发现任何业务交互,故实际上不作为“跨上下文”的用例来对待。

其次,这些业务用例中,从跨上下文协作关系角度来看,其中有些用例画服务序列图是会出现重复的,我们需要识别出来:

1. “创建新店铺”、“编辑店铺信息”,会用到短信验证码验证手机号,故都属于跨店铺、平台集成两个限界上下文的,且交互逻辑一致,故重复。

2. “加商品到购物车”、“选购接龙商品到购物车”,其实都是涉及到订单和商品两个限界上下文的相同交互关系,故重复。

3. “创建接龙活动”、“编辑接龙活动”,这两个业务用例的操作序列,从跨上下文协作关系角度来看也是完全一样的,只是后者需加载原有“接龙”上下文内部已持久化的信息、前者不用。

4. “创建付款订单”是“确认接龙付款”的子用例,故只需要保留“确认接龙付款”即可。

5. “添加品牌店铺到加盟列表”、“从加盟列表删除品牌店铺”,这两个业务用例都是涉及到店铺和加盟两个上下文的关系,并且都是获取店铺相关信息、并将店铺信息传输给加盟上下文处理,故重复。

最终,我们确定下来,被用来绘制服务序列图,进而确定各上下文协作关系的业务用例罗列如下图:

image.png

2基于跨上下文用例映射上下文关系

我们接下来的工作,就是要对这些业务用例,逐个进行技术分析,设计出服务序列图,然后根据服务序列图确定限界上下文的关系映射。

创建新店铺

创建新店铺涉及到手机号短信验证,故需要跨店铺和平台集成两个上下文。服务序列图如下:

image.png

基于该服务序列图识别出“店铺”和“平台集成”上下文关系如图(C 表示服务调用客户端、S 表示被调用服务端,以下同。DDD 标准方法中一般用“上下游关系”、及诸如“开发主机服务 OHS”等方式表达,但我认为那是废话,并没有清晰的表达强弱关联,故不在这里采用):

image.png

初始化店铺默认选项

根据产品 UI 原型的设计方案,新店铺创建后,系统机器人需要基于异步事件,对店铺的相关选项立即进行初始化:

1. 店铺默认门头图片(UI 允许创建人未设置门头图片);

2. 店铺是否开通订单短信提醒(随着业务发展可能会调整,故不放在创建店铺时设定);

3. 店铺的第一个员工(就是创建人自己);

4. 店铺默认的加盟分销政策(随着业务发展可能会调整,故不放在创建店铺时设定);

5. 店铺的首个接龙地点(详见产品 UI 原型,店铺接龙支持多个地点,但首个地点就是店铺地址);

6. 创建商家及商家账户(如果是创建人的第一家店铺);

7. 店铺默认商品分类(系统规则会按季节调整);

8. 店铺默认的商品搜索热词(系统后台会不定期根据某种策略更新);

这些默认选项,涉及到“店铺”、“员工”、“商品”、“接龙”、“商家账户”、“鉴权”共 6 个上下文的协作。服务序列图涉及如下:

image.png

根据该服务序列图,我们得出这 6 个限界上下文的协作关系如下图:

image.png

从上图的上下文依赖关系中,看到店铺对员工、商品、接龙、商家账户 4 个上下文产生了调用关系依赖,这是不合理的。因为从业务角度来说,其实是后 4 者依赖于店铺的存在而存在,而不是反过来。为此,我们做这样的调整:

1. 采用消息发布者/订阅者模式,让后 4 者依赖店铺上下文发布的“店铺已创建”消息;

2. 去掉“接龙”上下文对店铺首个接龙地点初始化的逻辑。本质上,仔细分析产品 UI 界面设计的要去,我们发现这其实是“群买菜小程序”在展示创建接龙活动的前端界面时,需调用“店铺”上下文服务来获取的信息:如果所选择店铺已经有接龙地址,则返回已有的接龙地址列表供选择;如果该店铺尚无首个接龙地址,则返回店铺地址作为默认接龙地址。

经过修改后的服务序列图如下:

image.png

根据该服务序列图,我们修改上下文的协作关系如下图(P 表示消息发布者,S 表示消息订阅者,下同):

image.png

加商品到购物车

客户浏览店铺商品,选中感兴趣的商品到购物车,以便后续的购买结算。考虑到添加商品到购物车中去的“时间”特殊性:我们需要在客户将商品加入到购物车时,为商品创建“快照”,以避免商品信息在后面被编辑修改(比如改了图片或描述、尤其是价格)时,影响到对客户的购买承诺。

为此,该业务用例(服务)就涉及到“订单”和“商品”两个上下文,服务序列图设计如下:

image.png

该序列图展示出订单和商品的上下文关系如图:

image.png

发送订单提醒

“发送订单提醒”需要在订单上下文中发起、“通知”上下文中发送通知,故涉及“订单”和“通知”两个上下文。该用例服务序列图如下:

image.png

考虑到订单消息提醒是没有副作用的、而且也不需要保证必须成功,故采用消息发布者/订阅者模式比较合适。也就是得到如下所示的“订单”和“通知”上下文的映射关系:

image.png

创建接龙活动

与“加商品到购物车”用例类似,商家在创建接龙活动、添加商品到接龙中去时也存在“时间”特殊性,需要为商品创建“快照”,以避免商品在后面被编辑修改(比如改了图片或描述、尤其是价格)时,影响到接龙活动的开展。为此,该业务用例(服务)就涉及到“接龙”和“商品”两个上下文,服务序列图设计如下:

image.png

该序列图展示出接龙和商品的上下文关系如图:

image.png

浏览我的接龙

按照产品 UI 设计文档,接龙只能在店铺下存在。而“浏览我的接龙”实际上是“浏览我被授权操作的所有店铺发布的、或其被授权店铺所加盟品牌店铺发布的、或我参与的”的所有接龙。故该用例涉及到“接龙”、“店铺”两个上下文,服务序列图如下:

image.png

相关文章
|
5天前
|
机器学习/深度学习 人工智能 并行计算
【AI系统】Kernel 层架构
推理引擎的Kernel层负责执行底层数学运算,如矩阵乘法、卷积等,直接影响推理速度与效率。它与Runtime层紧密配合,通过算法优化、内存布局调整、汇编优化及调度优化等手段,实现高性能计算。Kernel层针对不同硬件(如CPU、GPU)进行特定优化,支持NEON、AVX、CUDA等技术,确保在多种平台上高效运行。
53 32
|
5天前
|
存储 机器学习/深度学习 人工智能
【AI系统】计算图优化架构
本文介绍了推理引擎转换中的图优化模块,涵盖算子融合、布局转换、算子替换及内存优化等技术,旨在提升模型推理效率。计算图优化技术通过减少计算冗余、提高计算效率和减少内存占用,显著改善模型在资源受限设备上的运行表现。文中详细探讨了离线优化模块面临的挑战及解决方案,包括结构冗余、精度冗余、算法冗余和读写冗余的处理方法。此外,文章还介绍了ONNX Runtime的图优化机制及其在实际应用中的实现,展示了如何通过图优化提高模型推理性能的具体示例。
28 4
【AI系统】计算图优化架构
|
7天前
|
存储 人工智能 监控
【AI系统】推理系统架构
本文深入探讨了AI推理系统架构,特别是以NVIDIA Triton Inference Server为核心,涵盖推理、部署、服务化三大环节。Triton通过高性能、可扩展、多框架支持等特点,提供了一站式的模型服务解决方案。文章还介绍了模型预编排、推理引擎、返回与监控等功能,以及自定义Backend开发和模型生命周期管理的最佳实践,如金丝雀发布和回滚策略,旨在帮助构建高效、可靠的AI应用。
51 15
存储 人工智能 自然语言处理
36 6
|
6天前
|
机器学习/深度学习 人工智能 调度
【AI系统】推理引擎架构
本文详细介绍了推理引擎的基本概念、特点、技术挑战及架构设计。推理引擎作为 AI 系统中的关键组件,负责将训练好的模型部署到实际应用中,实现智能决策和自动化处理。文章首先概述了推理引擎的四大特点:轻量、通用、易用和高效,接着探讨了其面临的三大技术挑战:需求复杂性与程序大小的权衡、算力需求与资源碎片化的矛盾、执行效率与模型精度的双重要求。随后,文章深入分析了推理引擎的整体架构,包括优化阶段的模型转换工具、模型压缩、端侧学习等关键技术,以及运行阶段的调度层、执行层等核心组件。最后,通过具体的开发流程示例,展示了如何使用推理引擎进行模型的加载、配置、数据预处理、推理执行及结果后处理。
25 0
|
7天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
16天前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
31 3
|
25天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
7天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
105 68
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
9天前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
37 8