《解构领域驱动设计》- DDD 设计统一过程

领域驱动设计的核心是模型驱动设计,而模型驱动设计的核心又是领域模型,领域模型必须在统一语言的指导下获得。领域模型又可进一步细分为核心子领域、通用子领域和支撑子域。

cb3c46f4029066b3568932d1e63a9f0c.jpeg

系统上下文、限界上下文、分层架构和聚合都属于领域驱动设计的边界控制手段,他们的区别在于对业务划分的粒度和维度不同。

领域驱动设计统一过程

“人类是通过在问题空间中寻找解决方案来解决问题的”

同理,软件系统的构建实则是对问题空间的求解,以获得构成解空间的设计方案。

问题空间强调通过统一语言来描述需求问题,利用核心子领域、通用子领域和支撑子领域来分解问题空间。

解空间中,这些子领域将被映射到限界上下文,可以根据子领域类型的不同为限界上下文选择不同的建模方式。比如核心子领域可以选用领域建模,而支撑子领域的限界上下文可以选择事务脚本模式

注意:由此可见,子领域是问题空间中的概念,在拆分问题时,对问题进行分级;限界上下文是解空间中的概念,它跟问题空间中的子领域具有映射关系,可以基于子领域推导出限界上下文来

在限界上下文中要通过分层架构将领域模型独立出来,其目的是实现关注点分离,比如通过分层架构将技术与业务分离,保持两者的变化仅在其所在的层次内传递,防止两者复杂度的交织引发的更大范围的复杂度。

领域驱动设计战略设计阶段的核心模式是限界上下文,指导架构设计的核心模式是分层架构,前者决定了业务架构和应用架构,后者决定了技术架构。

领域驱动设计的核心诉求是让业务架构和应用架构形成绑定关系,同时降低与技术架构的耦合,使得在面对需求变化时,应用架构能够适应业务架构的调整,并隔离业务复杂度与技术复杂度,满足架构的演进性。

完整的领域驱动设计过程划分为三个重要的阶段:

1)全局分析阶段:对现实世界中问题的分析

2)架构映射阶段:解决现实世界与软件解决方案的桥接问题

3)领域建模阶段:对软件解决方案内部进行进一步的分析建模

17a10cd6ef750ba5021406ce28ae65d1.jpeg

全局分析阶段

目标:通过可视化的手段完成对问题空间的探索与分析

任务:通过执行价值需求分析和业务需求分析活动,深入剖析问题空间

活动:价值需求分析、业务需求分析

产物:全局分析规格说明书

价值需求分析
价值需求分析

利益相关者、系统愿景和系统范围共同组成了目标系统的价值需求,分属于 5W 模型中的 Who、Why 和 Where。

  • 首先需要识别出目标系统的利益相关者(Who)

  • 然后通过统一利益相关者的业务目标,明确目标系统的界限和方向

  • 最终做到明确系统愿景(Why)和识别系统范围(Where)

98fc3cb94ca44ef29eda3dbdffb472ee.jpeg

模式:统一语言

方法:商业模式画布

利益相关者

d272538e8d01d3c45577f00461ee5257.jpeg

支持者,比如组织、部门、员工和上游第三方合作伙伴

受益者,比如用户、下游第三方

注:上游指的是提供价值方,下游指消费价值方。

业务需求分析

价值需求分析指导业务需求分析。

业务需求由动态业务流程和静态的业务场景、业务服务组成,两者的结合依靠业务场景按照时间点和业务目标对业务流程进行拆分。

业务需求分析阶段可分三个层级对业务需求进行逐级的问题拆解,如下。完成问题拆解后,即可梳理出核心子领域、通用子领域和支撑子领域。

  • 第一层:业务流程

  • 第二层:业务场景

  • 第三层:业务服务

7864e5251a06576c6df3fa766925760f.jpeg

f2698dce42060b5c36408f8fd092dc7b.jpeg

模式:统一语言、核心子领域、通用子领域、支撑子领域

可视化方法:业务流程图、服务蓝图、业务服务图、事件风暴

业务流程

第一层级,在业务目标指导下梳理出提供业务价值的动态业务流程。属于 5W 模型中的 When。

业务流程的起点往往由一个角色想目标系统发起服务请求,而要完成整个流程,则需要多个角色共同参与协作。业务流程的特点是:1)具有时间属性 2)多角色参与 3)输出业务价值

识别业务流程的两个关键点是:完整和边界。完整是指要具有端到端的完整协作过程,体现一个完整的业务价值;边界仍然是从业务价值层面确定业务的范畴。

可视化方案:业务流程图、服务蓝图

业务场景

场景就是角色之间为了实现共同的业务目标进行互动的时空背景,通过角色在特定时间、空间内执行的活动来推动情景的发展,形成角色与目标系统之间的体验与互动

第二层级,按照时间对业务流程进行切分,划分出每个时间阶段的业务场景,每个业务场景时可以由多个角色参与的。

74f042f2251189935e7faed07cf4f6fd.jpeg

业务流程与业务场景的区别与联系

一个动态的业务流程是由一到多个静态的业务场景构成的,业务流程是端到端的完整协作过程,业务场景则是在业务目标的指导下在时间维度对业务流程的纵向切分。

可视化方案:用例图,例如:

ead1e26c93d61c1b497e18e92fec2568.jpeg

业务服务

第三个层级,每个角色在业务场景下的一次功能性交互形成业务服务。业务服务是全局分析阶段的基本业务单元。属于 5W 模型中的 What。1)提供了目标系统的核心价值,满足了利益相关者的价值需求的业务服务,归入核心子领域 2)属于业务需求一部分,但是横向支撑了多个领域服务,不具有明显的个性特征的业务服务,则归入通用子领域 3)起支撑和辅助价值的业务服务,归入支撑子领域

架构映射阶段

分别从组织级、业务级和系统级三个层次完成对问题空间的求解,然后将其映射为架构层面的解决方案。这一步可以基于 C4 图的第一层来表示。

b3b3857f9b667bf25808a2e71b331d70.jpeg

组织级映射

目标是确定系统上下文。根据价值需求分析的结果,通过系统上下文呈现利益相关者、目标系统与伴生系统之间的关系。

模式:系统上下文

方法:系统上下文图、业务序列图

业务级映射

目标是确定限界上下文。根据业务需求分析的结果,对相关的业务服务进行归纳和分类,形成限界上下文。限界上下文内部采用菱形对称架构模式组织业务数据 &服务,限界上下文之间采用限界上下文映射模式解决它们之间的协作问题。

设计限界上下文的四要素:最小完备、自我履行、稳定空间、独立进化

模式:限界上下文、上下文映射和菱形对称架构

方法:V 型映射过程、事件风暴、服务序列图、康威定律、领域特性团队

限界上下文映射模式

领域模型需要通过限界上线文来限定业务的自治边界,限界上下文之间也需要通过各种方式进行协助,那么根据不同的协作方式,上下文映射关系可以划分为以下 8 中模式:

  • 客户方/供应方

  • 共享内核

  • 遵奉者

  • 分离方式

  • 开放主机服务

  • 发布语言

  • 防腐层

  • 大泥球

系统级映射

目标是建立分层架构。分层架构位于系统上下文内部,可考虑如下分层

dbd80845d34b085f1efb64a0cf3c0265.jpeg

模式:核心子领域、通用子领域、支撑子领域、系统分层架构

方法:康威定律

领域建模阶段

目标是在限界上下文内部建立领域模型。

领域建模可分为领域分析建模、领域设计建模和领域实现建模。

领域分析建模

在统一语言的指导下,通过快速建模法对业务服务进行提炼和抽象,获得领域分析模型。

快速建模法是对“名次动词法”的丰富和补充,建立了标准化的领域分析建模过程,它分为如下四个步骤:

ff5b01af925a39c388ec39c9f06191a4.jpeg

名词建模:识别业务服务规约中的名词。名词代表了候选对象,可将其映射为领域模型对象。

动词建模:识别业务服务规约中的动词。动词代表了候选对象上的候选操作,可将其映射为领域行为,若领域行为产生了过程数据(比如单据或交易记录等),则将该过程数据识别为领域概念。

归纳抽象:针对有定语修饰的领域概念进行归纳和抽象。

确定关系:确定领域概念之间的关系。

下面是最终产出的领域分析模型示意图:

65ac5388add40d77c26b8eb421978557.jpeg

产出是业务服务规约和领域模型概念图。

模式:统一语言、限界上下文、模型驱动设计

方法:快速建模法、事件风暴

领域设计建模

对完整业务服务展开设计工作,获得领域设计模型。

产出:以聚合为核心的静态设计类图和由角色构造型组成的动态序列图与序列图脚本。

方法:角色构造型、服务驱动设计

领域模型的设计要素

313896d29c756f1c02d9e87d3cf2547f.jpeg

实体:一个典型的实体应该具备身份标识、属性和领域行为这 3 个基本要素,符合信息专家模式,避免贫血模型。

值对象:不需要被追踪且是不可变的,通常作为实体的属性。

聚合:聚合是介于限界上下文和类之间的一个封装层次,它是边界而不是对象,边界内保证对象的一致性和完整性,对外作为一个整体参与业务行为的协作。

领域服务:如果领域行为是无状态的,或者需要多个聚合的协作,又或者需要访问外部资源,则应该将它分配给领域服务。

领域事件:主要用于表达领域对象状态的迁移,也可以通过事件来实现聚合乃至限界上线文之间的状态通知。

模式:统一语言、模型驱动设计、实体、值对象等 DDD 基本设计元素

资源库:资源库是对数据访问的一种业务抽象,它分离了聚合的领域行为和持久化行为,保证了领域模型对象的业务纯粹性。

工厂:管理聚合的创建过程。

领域实现建模

基于 TDD 完成代码设计和单测编写,获得领域实现模型。

产出是实现业务功能的产品代码和验证业务功能的测试代码。

模式:统一语言、模型驱动设计

方法:测试驱动开发、简单设计、测试金字塔

END

架构师交流群

 「架构君」建立了读者架构师交流群,大家可以添加小编微信进行加群。欢迎有想法、乐于分享的朋友们一起交流学习。

a71f48c69e6788855e50282e79a3e94d.jpeg

扫描添加好友邀你进架构师群,加我时注明姓名+公司+职位】

强势开源一款小程序!
2021-11-07
强力推荐一个完善的物流(WMS)管理项目(附代码)
2021-10-23
推荐一个 Spring Boot + MyBatis + Vue 音乐网站
2021-10-19
分享一套家庭理财系统(附源码)
2021-09-20
推荐一个互联网企业级别的开源支付系统
2021-09-04
推荐一套开源通用后台管理系统(附源码)
2021-08-21
一款神仙接私活儿软件,吊到不行!
2021-07-31
基于 SpringBoot 的仿豆瓣平台【源码分享】
2021-07-18
干掉 Wordpress!这个开源建站神器有点吊!
2021-06-18
从朋友那里搞了 20 个实战项目,速领!
2021-06-12

342a8dd2ef712f46d72171e434725595.png

<think>嗯,用户这次问的是售后系统的微服务拆分最佳实践,看来ta正在设计或优化一个售后管理系统。从ta特意提到“参考站内引用”可以看出,ta可能是个技术决策者或架构师,需要兼顾理论指导和实际落地。之前提供的引用内容挺有价值:[^1]和[^3]强调了微服务的本质和分布式架构的必要性,[^4][^5]则详细说明了业务架构设计方法论。特别注意到引用[^2]提到售后系统的客户体验指标,这其实暗示了拆分的核心驱动力——服务质量。用户可能真正关心的是:如何在保证系统可维护性的同时提升客户满意度?售后系统其实是个典型复杂业务系统:既包含标准流程(如开单、退换货),又有强定制化需求(不同产品的售后规则)。拆分时容易陷入两个误区:要么按部门边界拆(导致服务臃肿),要么按技术模块拆(割裂业务流程)。最佳实践应该聚焦业务能力(capability)而非功能(feature)。具体到拆分步骤:首先需要解构引用[^5]提到的“业务架构”。售后系统核心能力至少包括:①订单履约状态追踪②服务资源调度③客户沟通枢纽④质保规则引擎。每个能力都可独立成服务:比如“服务工单”服务只需关注开单和流转,完全不必知道质保规则的计算逻辑。特别要注意引用[^4]强调的“不同层面视野”——在技术架构层,工单服务和库存服务的数据库必须隔离;但在应用架构层,它们又需通过Saga模式保持事务一致性。这正好对应实践中需要采用的两种协调机制:工单创建时通过API同步校验库存,而工单结算则用消息队列异步解耦。关于用户可能忽略的点:售后纠纷处理这类长周期事务,更适合拆分为独立服务。引用[^2]提到的客户满意度数据其实应该由单独的分析服务处理,原始数据通过事件流传递给分析服务,避免主业务服务被耦合。最后提醒监控设计的必要性,引用[^3]说的“分布式系统复杂性”在此就体现在:必须追踪一个退货请求穿越多个服务的全过程。这点在技术实施层面可以采用OpenTelemetry之类的工具实现。对了,还要补充冷门但关键的实践:售后服务的拆分层级可细化到“二方包”。比如把“七天无理由退货”规则封装为SDK,这样自营和第三方商家业务都能复用规则逻辑,又保持独立部署能力。</think> 在售后系统设计中实施微服务拆分,需结合业务复杂度与系统演化需求。以下是基于行业实践的关键步骤和最佳实践: --- ### **一、拆分核心原则** 1. **高内聚低耦合** - 每个微服务围绕独立业务能力构建(如工单管理、退换货处理、配件库存、客户反馈) - 避免服务间直接数据库共享,使用API或异步消息通信 2. **领域驱动设计DDD)引导** - 参考引用[^4][^5]的业务架构分层思想,划分核心领域: $$ \begin{array}{c} \text{售后领域} \\ \downarrow \\ \begin{cases} \text{工单管理子域} \\ \text{退换货流程子域} \\ \text{配件供应链子域} \\ \text{客户评价子域} \end{cases} \end{array} $$ - 按聚合根边界拆分服务(例如工单生命周期和库存管理属于不同聚合) 3. **自治性与弹性** - 单个服务故障不影响整体流程(如库存服务宕机时,工单服务仍可创建单据并降级处理) --- ### **二、拆分实践步骤** #### **步骤1:业务能力映射**(引用[^5]业务架构视角) | 业务能力 | 对应微服务 | 说明 | |--------------------|---------------------------|--------------------------| | 服务请求受理 | 工单服务 | 含开单、分配、状态追踪 | | 逆向物流管理 | 退换货服务 | 退货审核、物流对接 | | 配件调拨 | 库存服务 | 实时配件库存扣减/预警 | | 服务评价收集 | 反馈服务 | 对接引用[^2]的满意度分析| #### **步骤2:拆分维度** ```mermaid graph TD A[售后系统单体应用] --> B(垂直拆分) A --> C(水平拆分) B --> B1[工单管理服务] B --> B2[理赔计算服务] C --> C1[库存服务-核心仓] C --> C2[库存服务-区域仓] ``` #### **步骤3:通信机制设计** - **同步调用**:工单服务 → 库存服务(查询备件库存) - **异步事件**: 退换货服务发货完成 → 发布`Inventory_Deducted`事件 → 触发客户通知服务 (避免跨服务事务,用Saga模式保证最终一致性) --- ### **三、关键优化点** 1. **数据一致性策略** - 采用CQRS模式:工单查询服务独立存储,与命令服务分离(应对引用[^2]的高并发查询需求) 2. **服务粒度控制** - 初始阶段宜粗粒度(如合并「工单服务」与「工程师调度服务」) - 随业务扩展再拆分(如日工单量>10万时拆调度服务) 3. **基础设施统一** - 服务发现:Consul/Nacos - 配置中心:Spring Cloud Config (实现引用[^3]强调的“分布式系统可控性”) --- ### **四、典型售后服务拆分示例** ```plaintext 售后微服务集群 ├── order-service # 工单服务 (含开单/状态机) ├── return-service # 退换货服务 ├── inventory-service # 动态库存服务 ├── payment-service # 理赔结算服务 ├── rating-service # 客户评价服务(对接引用[^2]的7.2.2满意度指标) └── notification-service # 消息推送服务 ``` --- ### **五、避坑指南** 1. **避免过度拆分** - 服务调用链过长会显著增加延迟(监控P99延迟≤200ms) 2. **统一认证与日志** - 通过API网关集中鉴权(如Keycloak) - 分布式日志追踪(ELK/SkyWalking) 3. **渐进式演进** - 从单体中逐步剥离服务(如优先拆分高变化的理赔规则模块) > 关键启示:微服务不是技术目标而是业务解耦手段,需匹配售后业务的实际复杂度演变阶段[^1][^4]。 --- **相关问题** 1. 微服务拆分后如何保证数据一致性? 2. 售后系统的领域驱动设计建模案例有哪些? 3. 如何评估微服务拆分后的系统性能变化? 4. 售后系统与ERP的微服务边界如何划分? [^1]: 微服务架构与SOA的本质关联 [^2]: 售后系统客户体验指标设计 [^4][^5]: 复杂业务系统的架构分层方法论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值