“DDD 模型通常在白板或便利贴上开发。”这句来自一位从业者对 Context Mapper 工具的观察，点出了一个几乎每个领域驱动设计实践者都默认接受的事实——上下文映射靠手绘。可手绘的保质期比想象中短得多。第二天再打开那张白板照片，你很难区分哪些边界是当时敲定的，哪些只是临时讨论画错的线。

更麻烦的是，白板图跟不上代码库的演进。一旦数据库模式新增了跨越上下文的外键，没有人会记得把画好的图改一版。日子一久，图上的耦合关系悄悄走形，而真实的耦合还在数据库里不停堆积。有个后端团队分享过一个典型困局：最初不过是一条简单的 JOIN——payments.transactions ON orders.payment_id = payments.id，结果“最终变成了耦合地狱”。他们花了三年多的时间想从那张大数据库中把核心业务逻辑拆出去，因为到准备拆分时才发现，几个月积累下来的跨模块外键早已缠成了一团，没有任何视图能让团队看清楚这些依赖的规模。

打开网易新闻 查看精彩图片

Schemity 给了一个完全不同的解法：不要画图，直接从数据库模式里导出上下文映射。Schemity 是一款面向软件工程师的离线 ERD 工具，它的上下文映射功能建立在一个简单的观察上：每一条跨越上下文边界的外键，本身就是映射图上的一条边。一旦接受了这一点，建模步骤就消失了。开发者在平时梳理数据表关系时，会把一组彼此关联的实体保存成一个上下文视图（context view），这就是有界上下文的自然容器。而上下文映射不过是把这些视图提升一个层级：每个视图缩成一个节点，只要视图 A 中的某个实体持有指向视图 B 的外键，就从 A 到 B 画一条箭头。

箭头上还会带上一个计数值，标注朝这个方向有多少条外键。双击箭头，立刻就能看到具体的外键列表。整个过程不需要新增任何人工模型，上下文就是你在处理模式时已经保存过的那些视图，而映射图只消从视图列表里点一下就出来了。用 Schemity 的开发者甚至不用专门切换到“上下文映射”界面，视图和映射始终保持同步，因为数据来源就是同一套外键关系。

工具的联合创始人用自己搭建的一个多租户应用做了演示。当他把支付、订单、租户管理、通知等几个业务模块分别建立起对应的上下文视图后，上下文映射图立刻生成了节点和带数字的箭头。一眼就能看出哪些模块形成了上游对下游的依赖，哪些方向上外键特别多，就像在看一张会自己更新拓扑图的架构快照。这种实时性才是解决耦合堆积的关键——团队再也不用等着下一个“拆分灾难”，因为耦合程度已经以可阅读的方式始终摆在眼前。

过去维护上下文映射的痛苦，本质上是地图和地形分属两套系统：代码即地形，画图即地图，两者之间没有任何强制同步。Schemity 的做法正好反过来，它让地图直接长在地形上面。不用白板，不用 DSL 补充文件，也不靠任何人的记忆力，你最诚实的依赖关系全在外键里，只是缺了一个能把它投影出来的视角。