商品领域ddd_系统规模大、软件复杂？试试 DDD 架构设计！

作者 | 一切即心 责编 | 伍杏玲

Vaughn Vernon 在《领域驱动设计精粹》书中这样讲到：“一旦创新停滞并进入维护期后，我们该如何继续维持通用语言？事实上，最佳的学习方式，即知识获取，将在一段很长的时间持续发生，甚至发生在所谓的“维护期”。团队如果认为创新在维护期开始就结束了，这本身就是一个错误。”

对于一个产品而言，创新贯穿了整个生命周期，从探索到拓展，再到维护，乃至退出，每个阶段都需要持续创新。我们不能将创新局限在新的功能和新的服务上。同时，商业模式、用户体验以及质量改善也都可以是创新的发力点。

当产品进入了稳定期或是维护期时，我们需要在现有都高价值业务流程上延伸出新的创新，有时是入口创新，如近几年很多成功的产品，都从 PC 端转向了移动端，但核心的用户体验或是业务场景还是以原有的为主。有时候是模式创新，如 Microsoft 从多年的 Office 私有化服务最终转向了公有云的商业模式，并一举获得了巨大的成功。

没错，创新贯穿了产品整个生命周期，团队需要不断的获取知识，才能持续创新。

站在技术的角度架构的升级也是一项大的创新，今天这篇文章是写给自己的一篇总结，反思自己在系统架构设计上知识的不足，导致系统繁杂度上升以及维护的成本变高，通过优化系统架构提升产品的体验。

案例背景

我们以一个美容院前台的视角来了解一下美容院业务知识。美容院前台的工作主要为 收钱 和 算账 两个环节。一天从早到晚接待了多少个客人，收到了多少现金以及会员卡消费多少钱等等，下班之前是需要进行核对的，这也是收钱 和 算账 两环节。我今天分享的内容，就是和收钱、算账有关。

我们来看看e美数美业运营管理系统的组织和系统。(部分)

简单解释收钱板块下各子板块的意思。

服务：美容院属于服务行业，服务是必不可少的，比如，SPA、按摩等等；

产品：销售的实体商品；

卡项：储值卡、次卡、年卡、套餐卡等等卡项业务；

续卡：卡内没有钱了进行充值业务；

... ... 

那前台如何核对账单与算账呢？前台在下班前，首先要核对一天的现金流水(现金、POS、微信、支付宝等等)，核对一天会员划卡多少钱(从会员卡里面扣)，核对一天卖了多少会员卡和有多少会员续卡等等。那这些数据从哪里来呢？如下图：

前台需要到各个业务板块中去核对账单，当某一天客流量大的时候核对一天的流水单确实是一个很累的活。

有一天某企业要求规范前台，每天必须把当天的流水单录入到系统，当某天的企业后台财务算账时出现问题的时候，需要将那笔流水单(指业务板块记录)进行撤销。同时前台需将该流水单录入到系统，并且录入到实际收款的那一天。这个时候则会出现问题，系统需要将录入时间与结算时间进行区分，也就是说收款日期和操作日期。这个时候则发现，需要在所有的业务板块进行添加操作时间字段，同时进行添加代码。这工程量不小，比开发的时间都要长。

另外，企业财务计算各门店员工工资的时，需要将各业务板块的数据导出计算。工资计算系统在计算各员工工资时也需要将各业务板块的数据进行汇总，业务报表的数据也来源于各业务板块，导致系统之间高度的耦合，牵一发动全身。

问题来源

系统出现此类问题主要来源：

一、研发初期追求速度，为了快速上线，系统缺乏设计。目前大多数系统一开始并不是就大而全，而是通过不断的加功能点，通过用户的反馈快速响应迭代而成。

在系统不断升级过程中则会出现只考虑到点上面的问题，比如，e美数产品中充值业务是后加的，在功能升级过程中只考虑了充值业务，仅将金额充值到了会员卡，只记录了充值记录，并未考虑到订单以及前台、财务人员核对账单问题。

二、面向过程式编程，围绕数据表进行开发。当出现新的需求时，主要通过设计表，通过各种数据表之间的关联来满足需求。同时依据表模型来实现业务，无形中则让业务关系耦合加深。

三、知识的不足，缺乏设计复杂系统的经验教训，导致在设计系统时延用以往的开发经验使得系统缺乏灵活性，从而导致系统后期升级维护成本升高，修改较为困难。

为什么要使用 DDD(Domain Driven Design)

我们来看个例子是我们最近要进行研发的项目(某小程序)，该小程序满足以下几点需求，用户通过扫码访问小程序注册变成用户，用户可以通过在线充值变成会员(VIP1、VIP2... ...)，用户和会员都可以进行购买商品，商品里面分虚拟项目、实体商品和套餐项目。虚拟项目需要去店内使用，实体商品用户购买可通过店内自取或通过快递发送。套餐则是包含了多次的服务项目。这里主要讲商品，其它业务不在赘述。

商品该如何设计？

开发的思维则立马去设计表或者脑子里面考虑如何实现，这规则那规则等等。比如，t_product 里面名字、价格、类型(1、虚拟；2、实体；3、套餐)等等。设计完后就去写代码了，写完之后上线，有一天需求方说实体商品上需要加一个会员价，然后跑到 t_product 表中加个会员价字段，紧接着增删改查来一遍，还给客户加了一个批量设置会员价的功能，自我感觉挺棒，完事收工了。突然，有一天需求方说VIP1、VIP2 享受的优惠不一样，抓瞎了。

相信很多人都有以上的经历，我们通过 DDD 建立领域模型，商品属于核心域，虚拟商品、实体商品、套餐商品为子域，温馨提示则是虚拟商品和套餐商品的支撑域。模型如下图：

product(v1.0)

我来看一个更直观的图 如下：

DDD 有限界上下文概念，我们通过限界上下文，虚拟商品、实体商品、套餐商品各司其职，自己干自己的事情。当未来出现xxxx商品，仅仅只需要实现xxxx商品的业务逻辑。

DDD 通过领域建模让业务变得更加清晰，这种方式全程都在讲领域，比如 商品域、订单域，各干各的事情。限界上下文则是域的边界，比如，虚拟商品上下文，只干虚拟商品的事情。

DDD 指导架构设计与建模

我们回到最开始的案例问题，前台工作收钱 - >算账，企业财务工作也是 算账。目前前台和财务算账都是通过业务数据，比如服务、产品的记录来核对，计算薪资。数据报表的数据也来源于各业务板块。

那如何解决这些问题？

构建流水单系统，前台和财务统一查看流水单系统进行核对营业流水，通过流水单进行计算员工薪资，无需通过各项业务记录进行核对。

同时，研发在建立报表系统时，可以减少从各项业务数据中抽取，汇总到报表系统，只需要对接流水单系统。如下图：

假如，某一天企业需求发生变化，出现了新当业务时候，则只需要实现新业务的上下文。

通过 DDD 限界上下划分分析后，就会发现，应该把每个业务的上下文单独实现，流水单系统接管交易行为。

以上是个人在学习 DDD 路上的一点总结，写得比较糙，自己也是在慢慢摸索的路上。

总结一点，DDD 是一门方法论，它可以帮助开发更清晰的理解问题、理解用户的期望。

 热 文 推 荐  ☞ 程序员因接外包坐牢 456 天！两万字揭露心酸经历 ☞ 年薪 170 万阿里 P8 程序员征婚上热搜，程序员婚恋观大曝光！ ☞ 中台的末路 ☞ 对话行癫：CTO 最重要的是判断未来！| 人物志

☞云栖大会|当数据中台遇上智能 看中台“鼻祖”阿里巴巴又有什么新花样？

☞对比C++和Python，谈谈指针与引用

☞肖仰华：知识图谱构建的三要素、三原则和九大策略 | AI ProCon 2019

☞ 以太坊交易量第一合约FAIRWIN被爆漏洞, 竟是因为这个接口被滥用…… ☞厉害！ 接班马云的为何是张勇？

你点的每个“在看”，我都认真当成了喜欢