穿越古代商帮搞DDD：用限界上下文拯救烂账本

人这一辈子，总要碰上几次"系统崩了"的时刻。我脑子里的最后记忆，是凌晨三点盯着监控大屏上飙升的错误率，然后眼前一黑。再睁开眼时，面前没有服务器日志，只有一摞墨迹未干的账本。外头有人扯着嗓子喊："分号又断账了！账房打起来了！"我摸了摸身上——长衫、算盘，还有半块没啃完的干粮。我穿越了，成了古代商帮的一名账房先生，而整个商帮的记账体系，已经乱到了随时破产的边缘。

我下意识在袖口里摸手机，自然是摸了个空。等冷静下来，看着满桌的出入库凭据、银票存根、赊欠契约，我忽然意识到一件事：这不就是一套没有领域模型、没有限界上下文的遗留系统吗？谁说DDD只能在现代软件里用？业务就是代码——不管这代码是用Java写的，还是用毛笔写的，业务规则摆在那里，复杂度摆在那里，崩塌的方式也摆在那里。

这篇文章是这个系列的第1集。我打算从"账本崩塌"这个事故现场开始，把现代软件工程里的领域驱动设计（Domain-Driven Design，DDD）方法论，搬进这家古代商帮。这一集讲清楚三件事：旧账房系统是怎么一步步腐烂的、如何用战略设计画清商帮的业务边界、以及设计战术建模时最容易被忽略的坑。后面几集再展开防腐层、领域事件和渐进式迁移。

先说一句：故事是虚构的，但方法论是真的。每一处建模取舍，放到今天的业务系统里依然成立。

1. 账本崩溃不是算错数：旧商帮系统的四条病根

1.1 所有业务挤在同一本"万能账"里

我上任第一天干的事情，不是去安抚伙计，而是把总账房的账本全部搬出来。一摞摞翻下去，发现了一个惊人的事实：总账、流水账、仓库账、银号往来账，全都记在一本通用的大账册里。

一笔业务在账上长这样：

• 三月十二，收东街王记绸缎庄货款三两二钱，支库房麻绳两根，欠伙计李四月钱百文未付。

这行字里，至少混了三个业务领域：销售结算（货款）、库存变动（麻绳出库）、薪资（伙计李四月钱）。它们被强行塞进同一张"流水表"里，没有单据类型、没有账目分类、没有归属的部门。

放到现代系统里，这就叫"大宽表综合征"。所有业务共用一张表、一套字段、一个接口，字段名充满歧义，"备注"列里塞了半结构化数据，每个团队都往里加一列，最后几万行代码耦合在一起，谁也拆不动。

商帮的账房也一模一样。表面上是"一本账齐了"，实际上每一笔账都牵动多个业务域，只要一个环节记错，整本账就对不平。这不是算数水平的问题——算盘能算出加减乘除，但算不出业务边界。

1.2 伙计们说自己的话，账本讲账房的理

第二个病根是语言混乱。我花了一个下午，把店堂、库房、银号、柜房的人分别叫来问："昨天那笔出货，你们怎么记？"

店堂伙计说："卖出去三匹布，客人赊着的。" 库房管事的说："出库三匹布，库存少了三匹。" 银号掌柜说："入账两匹布的钱，另一匹兑成了旧票据，折了七成。" 账房先生则说："一笔业务，三处都写了，凭证编号不一样，对账的时候谁也找不到谁。"

这不是记账方法的问题，这是**通用语言（Ubiquitous Language）**的缺失。一个"卖布"的动作，在不同人嘴里变成了"赊销""出库""入账""折兑"四套话语体系。账本没有一套统一的业务词汇，大家各自为政，最后对不上账的时候互相甩锅。

现代系统里，这个场景更常见。同样一个"客户"，CRM里叫"客户"，订单系统里叫"买家"，财务系统里叫"往来单位"，统计系统里叫"用户"。字段名五花八门，口径互不相认，跨部门取数永远要开评审会。业务语言不统一，建模就无从谈起。

1.3 业务规则藏在人的脑子里

第三个病根更隐蔽，也更致命：关键的经营规则没有任何载体，全在关键人物的脑子里。

"老主顾赊账上限多少？"我问。 账房老掌柜斜眼看我："这还用问？王记绸缎庄赊过三百两封顶，再多就要东家点头。" "那周记粮行呢？" "他是老东家的亲家，四百两也批。" "新来的赵家布行？" "先交一半现银才发货。"

你会发现：信用政策、赊销额度、审批流程、库存调拨规则，全凭老掌柜一人记忆。他生病告假，整个分号的赊销业务就瘫了；他记岔了某个客户的额度，账房就多了一笔坏账。这不是管理问题，这是业务规则没有显式化（Business Rule not Externalized）——放到代码世界里，就是一堆散落在各个方法里的"magic number"和隐式判断，没有任何配置、没有版本、没有测试覆盖。

1.4 最要命的：单据之间互相矛盾

旧账房有一套自己的"凭证体系"——进货有进货单，销货有销货单，汇款有汇票，赊账有欠条。听着挺全，但单据之间从不互相校验。

银号说："这张汇票盖了章，能兑一百两。" 库房说："没见货物出库。" 店堂说："客户拿走了货，欠条在我这。" 三方各执一词，账房对账时只能靠一张一张人工比对，碰上有疑点的单据，就要翻出积年的原始凭证来核。商帮越大，单据量越大，对不上账的缺口就越多。到最后，账房已经不敢对账了——因为对出来的窟窿补不上。

这个场景放到现代系统里，就是"分布式系统缺乏一致性保证"的古典版。订单、库存、支付三个系统之间存在大量异步交互，缺了明确的领域事件和补偿机制，数据对不平的时候，只能靠人肉画Excel表调账。

四条病根看下来，我确信了一件事：商帮需要的不是一本更厚的账本，而是一套经过领域建模的业务系统。能不能落地，取决于我们用什么样的方法去拆、去建模、去实施。

2. 先定疆界再动手：给商帮画出限界上下文

2.1 从业务活动里挖出真正的"业务边界"

做DDD的第一步，永远不是写代码，而是画业务地图。我花了两天时间，把商帮的完整业务动作梳理了一遍，凡是账本里出现过的业务事件，全列在纸上：

• 店铺卖出货物（赊销、现销、折扣、退货）
• 库房出入库（进货、调拨、盘点、损耗）
• 银号汇兑（开票、兑付、背书、贴现）
• 货栈中转（货物仓储、转运、保险）
• 分号往来（总号与分号的资金结算、利润分成）
• 人员薪俸（伙计月钱、掌柜分红、季度津贴）

我把这些动作分组，每一组问一句话："这一组活动，是不是有自己独立的目标、独立的规则、独立的术语？"

答案很明显。店铺销售关心的是"卖出去没有、钱收回来没有、客户能不能信任"；库存管理只关心"账实相符、货在哪儿、存量够不够"；银号汇兑关心的是"票据真伪、汇率、兑付时效"；分号结算关心的是"哪家分号赚了、哪家分号欠了总号多少钱"。

他们虽然都共享同一批物资和银子，但彼此的业务语言、业务规则无法直接混用。这就引出了DDD中最重要的概念：限界上下文（Bounded Context）。

每个上下文负责一块完整的业务领域，有自己的模式语言、自己的数据模型、自己的业务规则。店堂不知道库房内部的盘点周期，库房也不需要理解店堂的信用审批——它们之间只需要一份明确定义的"契约"。

在纸上，我给这家商帮画出了初步的限界上下文清单：

2.2 核心域、支撑域、通用域：先分清主次再谈投入

限定边界之后，还有一步更重要：判断哪个上下文是商帮的核心竞争力。

我做这个判断的基准很简单——如果这家商帮明天倒闭，最值得抢救的业务是什么？答案是汇兑和信用。商帮和普通货栈的差别，就在于它可以凭着一张汇票跨地域调拨资金，靠信用让商号之间互欠互还。销售和库存是必要的，但它们是"有钱就能干"的基础业务；汇兑、信用评估、分号资金平衡，才是这家商帮真正构筑的护城河。

这就是DDD里对领域的划分：核心域（Core Domain）、支撑域（Supporting Domain）、通用域（Generic Domain）。

• 核心域：汇兑上下文、信用/风险上下文（分号结算的一部分）。
• 支撑域：库存上下文、销售上下文——没有它们生意跑不起来，但它们不构成壁垒。
• 通用域：人事薪酬——市面上任何账房先生都懂，不值得投入战略资源。

这个划分直接决定后续的资源投入顺序。同理，在你的业务系统里，订单支付这类环节如果是核心，那就值得把建模做到毫厘不差；如果只是给核心流程提供支持的边角功能，就别浪费太多精力在它的"完美抽象"上，用现成方案快速搭好，把省下来的人力投入真正决定产品价值的领域。

2.3 上下文之间的关系：商帮里的协作契约

限界上下文不是孤岛，它们之间必然有协作。我把上下文之间的交互方式也梳理了一遍，对应到DDD的上下文映射（Context Mapping），基本是四种模式：

• 防腐层（Anti-Corruption Layer）：老账房与新的领域模型之间，必须有一层翻译逻辑。老账本的术语、字段格式、业务流程不能污染新系统，新系统的业务规则也不强行改造老账房。两侧各走各的规矩，中间靠一个翻译层对接。
• 共享内核（Shared Kernel）：销售和库存必须共享"货品"这个基础概念。货品的编码、名称、单位必须一致，否则一笔卖出和一笔出库对上不号。共享内核要小，越大耦合越重。
• 客户/供应商（Customer-Supplier）：销售上下文向库存上下文发起"出库申请"，销售是客户，库存是供应商。库存的响应速度和规则，由销售侧的流程需要驱动，但库存保有最终解释权。
• 事件驱动（Event-Driven）：银号兑付完成后，发布一个"票据已兑付"事件，分号结算上下文订阅后自动更新往来账。两边不需要同步调用，用事件解耦。

这一层梳理完，商帮的业务地图已经从"一团乱账"变成了"一张有边界、有协作的系统图"。乱局之下，我们终于找到了下刀的位置。

3. 重立契约与记账规则：用聚合把"账本"拆成可落地的领域模型

3.1 实体与值对象：银子与票据，谁该有身份？

边界画好了，下一步是进入每一个限界上下文内部，做战术建模（Tactical Design）。我先从问题最严重的"汇兑上下文"动手，因为它既是核心域，又是旧账房崩塌的重灾区。

第一件事，区分实体（Entity）和值对象（Value Object）。

我拿出两张纸，左边写"东西"，右边写"属性"。银票是有唯一编号的，一张银票在流通过程中要被背书、兑付、注销，它有自己的生命周期和身份，银票是实体。而上面的"金额""签发日期""付款方"这些属性，如果单拿出来，都只是一组数据，可以被替换、可以被比较值相等，它们是值对象。

这个区分看着简单，但实际建模时非常容易踩坑。我在商帮里看到的普遍错误是：把金额、日期这类值对象当成实体来管理，给每一笔入库的麻绳都建一个长长的流水主键，然后为了"记录每一根麻绳的轨迹"，把系统复杂度抬升了一个量级。如果你发现一段数据永远不会单独变化、不会需要独立追踪、只看值就能判定异同，那就把它做成值对象，省掉一半的样板代码。

3.2 聚合边界：一张票据管住一组不可分割的业务规则

第二个问题更关键：如何确定**聚合（Aggregate）**的边界？

我们拿"赊销"来做例子。一笔赊销业务涉及：客户信息、赊销单、赊销明细、还款计划。朴素的建模方式是把这几张表独立开来，各自有增删改查的接口——但这正是旧账房崩溃的根源之一。

我用一个场景来说明。账房伙计收到店堂转来的赊销单，他先登记客户欠款，又更新库存，再往总账写一笔应收账款。三个动作分散在三个地方，只要任何一个环节漏了、或者调换了顺序，账就塌了。

正确的做法是，把"赊销"定义为一个聚合，聚合根是赊销单。一切对这笔赊销业务的操作，都必须从赊销单这个入口发起：

• 新增赊销单，同时创建应收记录；
• 修改赊销单金额，同时校验客户累计欠款；
• 结算还款，同时登记回款流水。

聚合保证的是一组业务规则必须原子地执行，不可分割。库房不知道赊销单的还款明细，它只需要知道"某张赊销单要出库多少货物"；而客户欠款总额的维护，只在赊销单聚合内部完成。

这里有一个非常经典的实操教训：聚合不是越大越好。刚学DDD时，我也倾向于把"商帮"整个做成一个大聚合，客户、店铺、银号、仓库全盘打包，一个操作锁一整棵对象树。结果事务范围巨大、锁冲突严重、并发一高就死锁。后来我学乖了：聚合边界要小而稳，只圈住那些"必须一起变化的数据"。

在商帮场景里，我拆出了几个核心聚合：

• 赊销单聚合：赊销单（根）、赊销明细、还款记录；规则是"单笔赊销额度不可超五百两""客户累计欠款不可超其授信额度"。
• 汇票聚合：汇票（根）、背书记录、兑付记录；规则是"汇票签发后不可修改票面金额""兑付时印鉴必须与存根一致"。
• 库存批次聚合：商品批次（根）、入库记录、出库记录、盘点记录；规则是"任何出库不得导致批次余量为负"。

每个聚合只负责自己区域内的一致性，跨聚合的一致性通过后面的领域事件来协调。

3.3 领域服务与业务规则：把"老规矩"变成显式的代码

聚合负责管理数据的一致性，但有些规则不天然属于某个聚合，它们是跨越多个对象、甚至跨越几个上下文的业务决策。我把这类规则放进领域服务（Domain Service）。

举一个真实的例子。商帮有一条老规矩："凡赊销超过三百两，必须由大掌柜审批；超过五百两，需东家亲自画押。"这条规则放在哪个聚合里都有点尴尬——它涉及客户信用等级、赊销单金额、审批权限三个要素。放在"赊销单聚合"里会造成聚合过度膨胀，放在"客户聚合"里又管不到订单，放在应用服务里又容易被人绕过。

最终我在领域层里建了一个信用审批服务，专门承载这条规则：

public class CreditApprovalService { public ApprovalResult approve(Customer customer, CreditRequest request) { if (request.amount <= 300) { return ApprovalResult.passed(); } if (request.amount <= 500 && customer.grade().isTrusted()) { return ApprovalResult.needManagerApproval(); } return ApprovalResult.needOwnerApproval(); } }

这段伪代码的作用不是提供一份标准实现，而是展示一个思维转变：业务规则从"人的脑子里"搬进了"代码里"。老掌柜记得那三百两、五百两的门槛，但新来的账房先生不需要记——他要做的只是调用这个领域服务。规则有了载体，就有了版本、可测试、可追溯，这就是"业务即代码"最朴素的含义。

4. 新账房落地：防腐层、领域事件与渐进迁移

4.1 防腐层：在老账房和新账房之间架一座"翻译桥"

模型建好之后，最实际的问题是：商帮不能停业。总号还在运行，分号的旧账本还在天天流动，你不可能说"今天账房停工一整天，我们换新系统"。

旧账房就是这么硬的约束：它必须继续跑，但它的数据模型、字段格式、甚至业务含义，和新领域的模型没法直接兼容。在这种情况下，我在新旧系统之间加了一层防腐层（ACL）。

防腐层做的事情很简单：把旧账房的输入翻译成新领域模型能理解的语言，再把新领域的输出翻译回旧账房能记录的格式。

举个例子。旧账房记一笔"客户付款"，填的是：客户姓名、金额、日期、备注。新模型里的"客户"是有编码的，"付款"必须关联到一笔赊销单或汇票。防腐层收到旧账房的结构化数据后，先根据客户姓名字段去查新模型的客户主数据，找不到就创建一条"待认领客户"记录，再根据金额和日期匹配到对应的应收单，最后才生成一条标准的"收款登记"动作。

这个过程有脏数据、有极难匹配的边界case，我承认防腐层是全场最无趣又最不能少的代码。它不能产生业务价值，但没有它，老系统一句"术语不合"就能让整个改造计划停摆。

施工时我还留了一个细节：防腐层本身不做业务决策。它只是一座桥，所有"客户逾期未付要不要停止赊账"这类判断，必须下沉到领域层；防腐层里只做格式翻译和路由。

4.2 领域事件：分号一响，全城联动

跨上下文的数据一致性，我通过**领域事件（Domain Event）**来解决。

用现代的话说，这就是一个简单的发布-订阅机制：一个上下文完成某件重要的事，向其他上下文广播一个"已经发生的事实"，其他上下文按需响应。

我做的第一场"领域事件"实验，选在"票据兑付"这个场景上。以前，银号兑付一张汇票后，需要手工写两封信：一封给总账房更新往来款，一封给销售柜房核销客户欠款。两封信走的是不同的邮路，经常一封信到了、另一封信还在路上，账目永远跨月对不平。

改造后，银号兑付完成，发布一条"票据已兑付"领域事件。分号结算上下文订阅后，自动更新该商号与总号的往来余额；销售上下文订阅后，自动核销对应客户的欠款记录。整个过程不经过人手的二次录入，数据在多上下文之间保持一致的机会大幅提升。

我在设计事件时给自己立了三条规矩，这里也分享出来：

1. 事件名称必须是过去时，例如"票据已兑付""赊销单已违约"，它描述的是一个不可变的事实，不是一条指令。
2. 事件携带的数据要最小化，不要直接把整个聚合对象丢出去，只带聚合根ID和必要的状态信息，避免订阅方被无意义的细节污染。
3. 事件处理必须最终一致，订阅方接收事件后自己保证本地一致性，重试和补偿都是订阅方的责任，发布方不关心。

商帮的账目在第二十天的时候，第一次做到了"日清日结"——所有分号的往来、兑付、赊销，在次日清晨都能对齐上。这在旧账房时代是无法想象的事。

4.3 渐进迁移路线：别让老账房在改革当天就停业

最后是落地节奏。我没有选择"一夜换账本"，而是采用了一条渐进迁移路径。整个过程分四步走，每一步都以"老账房仍有唯一权威数据"为前提：

• 第1阶段：并行记录。新账房系统上线，但只做"影子记账"——所有单据仍走旧流程录入旧账本，新系统同步记录一份，两套数据每天人工比对差异。这一步的目的只有一个：验证新模型的领域规则是否完整捕捉了旧账房的业务行为。
• 第2阶段：单品试点。选一个影响面最小的单据类型（比如"店内调拨单"），切换成新系统记账，旧系统仍然保留，但停止对这类单据的权威记账。试点期间如果发现规则漏了，立刻回退。
• 第3阶段：按上下文切换。先切汇兑上下文、再切销售上下文、最后切库存上下文。切换顺序的原则是：先切核心域，因为它最能验证业务价值；同时每切完一个上下文，立即处理防漏层的对接。
• 第4阶段：退出旧账房。当所有上下文都迁移完成、并稳定运行一个完整账期后，旧账房数据归档，正式退役。

每个阶段之间，我都留了一个"能回退"的兜底。我听过的很多失败案例，都是因为"切了就回不去了"，结果上线当天发现规则遗漏，又不敢回退，只能用补丁的方式硬糊，糊到最后新系统又变成了另一个旧账房。

讲到这里，商帮的账本还没有彻底平稳运行第1集就没必要继续往下说了。但有一件事我觉得比账目本身更有价值——这套方法真正改变的，是让上到掌柜、下到伙计的每个人，都开始用一套统一的话语体系去谈业务。他们不再说"我那笔账""他那张条子"，而是说"赊销单""汇票""分号结算"。

我个人实际操作中的体会是：DDD最难的地方从来不是那些概念——限界上下文、聚合、领域事件都不难理解。真正难的是让人放下"用一套全能的账本管所有事"的执念。不管是古代的商帮，还是今天的研发团队，总有人觉得一张大表、一个超大聚合、一套万能接口才能包打天下。而DDD教给我们的恰恰相反：业务之所以复杂，是因为它有真实的边界；承认边界、尊重边界，改造才能走得动。

下一集，我准备聊聊自己在商帮里推行"领域事件驱动"时踩过的坑——比如事件风暴开到一半团队吵起来、比如订阅方丢了消息怎么补偿、比如"两个上下文都想当大哥"的治理难题。这些在今天的微服务治理里，都是同样要命的真问题。