换种方式讲技术：Domain Storytelling

说实话，你看过多少技术文档是真正能让你看下去的？大部分文档枯燥得要命，读两页就昏昏欲睡。传统技术文档最大的问题，就是连最基本的事都没做到——讲清楚系统为什么存在，以及它在实际工作中怎么运转。

Domain Storytelling 完全颠覆了这套玩法。

它到底是什么？

Domain Storytelling，说白了就是一群人坐在一起讲故事。不过讲的不是小说，而是系统是怎么运作的。

技术团队、业务专家、相关方，大家一起把系统的运作流程画出来。不用那些干巴巴的 UML 图，也不用堆砌几十页的需求文档，直接用画面讲故事——谁在什么场景下做了什么，事情的先后顺序是怎样的，为什么要这么做。

想象一下，你不是在看技术方案，而是在看一个人一天的工作日记。只不过这个"人"可能是用户、是后台系统、或者是好几个角色之间的协作。

具体怎么做呢？你要找出三样东西：

• 角色（Actors）：涉及的人和系统
• 行为（Activities）：他们实际在做什么
• 工作对象（Work Objects）：他们创建、修改或者使用的东西

把这三样串起来，就成了一条清晰的视觉流程线。谁都能看懂，不管是程序员还是完全不懂技术的人。

程序员为什么要关心这个？

实话告诉你，大部分技术债不是代码写得烂造成的。问题出在需求理解有偏差。

你以为你按客户说的做了，客户以为你完全理解他的意思了，结果一交付，两个人完全不在一个频道上。然后你就开始了凌晨两点的重构生活。

Domain Storytelling 能在项目早期就把这种偏差揪出来。当你能亲眼看到业务流程被画出来，问题就藏不住了——哪里有缺口，哪里重复了，哪里从一开始就理解错了，一目了然。

对于事件驱动系统来说，这点尤为重要——EventSourcingDB 这样的技术栈尤其依赖这一点。事件溯源架构的核心，就是看你能不能准确捕捉真实世界的业务行为。故事讲错了，你的 event schema 后期要修到吐血。

实际好处有哪些

新人上手快：不用啃几天文档，花几分钟看张图就明白系统是干嘛的。

少返工：写代码之前大家对"要做什么"达成共识。

沟通更顺畅：不懂技术的同事也能真正参与进来，而不是只会点头。

事件建模更清晰：做 event sourcing 的朋友会发现，聚合边界和事件之间的关系变得直观多了。

怎么开始？

你不需要什么花里胡哨的工具。一块白板、一堆便利贴、再加上一颗愿意倾听的心，就够了。

核心方法很简单：一直问"然后呢？"，直到把整个业务流程画完。过程中留意那些人们犹豫、争论、说"其实要更复杂一些"的地方——这些节点往往藏着领域里最真实的复杂性。

回到你的项目

不管你是在云服务平台上搭个简单落地页，还是构建一套复杂的分布式系统，这个原则都适用：理解技术方案背后的人的故事，才能做出真正好用的东西。

你的领域模型好不好，取决于你对领域的理解有多深。Domain Storytelling 给你提供了一种结构化、可重复的方式来建立这种理解，而且是一群人一起做。

下次你要规划新功能或者新系统，别急着写那份长长的需求文档。拿几支笔出来，先把故事讲清楚。

你有没有在项目里用过 Domain Storytelling？欢迎在评论区聊聊你的经历——踩过什么坑，又有哪些心得？