DDD战略建模在重构业务系统时的实践

最新推荐文章于 2024-07-16 09:21:44 发布

蔚1

最新推荐文章于 2024-07-16 09:21:44 发布

阅读量1.7k

点赞数 3

文章标签：后端系统架构大数据

本文链接：https://blog.csdn.net/valada/article/details/100026414

版权

本文介绍了作者在重构业务系统时应用领域驱动设计（DDD）的实践经验，特别是如何用限界上下文来保护领域。通过领域驱动设计，作者解决了业务和技术之间的难题，实现了财务核算级别的精确交付，降低了业务系统与外部系统的耦合。文章强调了理解业务需求的重要性，通过统一语言建立领域模型，并通过领域事件解耦与其他上下文的关系，保护了业务抽象行为的一致性。

摘要由CSDN通过智能技术生成

本文是作者结合 2019 年 07 月 12 日在 ArchSummit 全球架构师峰会 DDD（领域驱动设计）落地探索专场做的主题分享：《DDD 战略建模在重构业务系统中的实践》的内容整理而成。

我是来自罗辑思维得到 app 的韩宇斌，很荣幸能有机会和大家分享我的一些心得，我分享的主题是《DDD 战略建模在重构业务系统时的实践》，内容分为三部分：第一部分是：用领域驱动来把握真正的业务需求；第二部分：领域驱动设计指导架构设计与建模；第三部分：用限界上下文来保护领域。

如果把我的分享比作一个故事的话，那么故事的主线是：领域驱动设计帮助我解决了工作的难题。这个难题表现在两个方面，首先无路可退：入职第一个任务，做不成就意味着回家。其次是左右为难：实现技术重构的目标，满足不了业务需求！不去实现，又不知道该做什么？……

本文已参加 GitChat「我的技术实践」有奖征文活动，活动链接： GitChat「我的技术实践」有奖征文活动

大家好，我是来自罗辑思维得到 app 的韩宇斌，很荣幸能有机会和大家分享我的一些心得，我分享的主题是《DDD 战略建模在重构业务系统时的实践》。我分享的内容分为三部分：第一部分是：用领域驱动来把握真正的业务需求；第二部分：领域驱动设计指导架构设计与建模；第三部分：用限界上下文来保护领域。

在这里插入图片描述

用领域驱动来把握真正的业务需求

如果把我今天的分享比作一个故事的话，那么故事的主线是：领域驱动设计帮助我解决了工作的难题。这个难题表现在两个方面，首先无路可退：入职第一个任务，做不成就意味着回家。其次是左右为难：实现技术重构的目标，满足不了业务需求！不去实现，又不知道该做什么？

在进入到主题之前，我们先来从商家视角了解一些电商业务的背景知识。一个商家想要卖自己的商品，不管是在线下实体店面，还是线上电商，至少要有卖货，收钱，发货三个环节，如果我们从网上找一个开源的商城系统，也会包括这三部分的功能。然而，对于商家来说，只有这三个环节是不够的，还需要有一个非常重要的环节就是算账。我分享内容，就是和收钱，发货，算账相关的。

在这里插入图片描述

我们再来看一下得到 APP 电商业务涉及的组织和系统。我所在的听书属于业务后端，主要负责卖货和发货环节，而收钱环节需要由交易平台组和基础平台组提供的服务来完成，算账相关的由财务平台组负责。大家先对红框的三个系统有个印象，后面会频繁的提到。

在这里插入图片描述

得到 app 目前如何确认收入呢？财务部门在算账交税前，首先要确认收入，卖了多少商品，收了多少钱，实收账款和应收账款能不能对上。用户在 APP 内下单后生成订单记录，收到钱后生成支付记录，发货生成权益记录。虚拟商品的发货不需要快递，就是我们在表里面写一条数据。财务部门需要把三张记录表中的每条数据都用订单号关联起来，并且状态含义严格匹配，才能确认为是收入，否则就会成为坏账或者呆账，需要人工处理。

在这里插入图片描述

然而，开始的时候，并不是这样的。用户在 APP 中购买虚拟商品，我们没有生成订单记录，只有支付记录和权益记录。当出现数据不一致时，就给财务确收带来了问题。主要分为两类，只有支付记录没有权益记录数据，是有支付无交付，我们收了钱没发货；而只有权益找不到对应的支付记录的数据，是有交付无支付，发货了没收到钱。每个财务结算周期，两个开发组的人，几乎都要去排查问题数据。

你也许会好奇，一个电商平台居然没有订单？我相信“存在即合理”，当时这么做肯定有当时的原因和背景，说白了一切都是为了快速上线，快速验证得到 app 的商业模式，活下去对于创业公司来说，比设计实现一个完美的系统优先级更高。

在这里插入图片描述