用例形态

大多数业务用例之间的差异，并不像乍看之下那么大。见得多了，就会发现它们能归纳为数量不多的几种反复出现的形态。找到与你手头问题相符的形态，你就有了一份可以组装的初稿——一个可以拿来讨论、而不是最终定案的设计。

下面每一种形态，先说明它看起来是什么样子，再说明它通常由哪些部件组装而成。这里说的是部件的种类和作用，而不是具体的产品——真正的构建部件在平台自身的部件库中。

1. 交易处理器

它是什么样子： 有人用大白话提出请求，想要一个报价或配置好的东西——一份报价单、一次预订，或者为他们量身核算出的具体方案。

通常由以下部件组装而成：

它是什么样子： 单据不断送达——发票、申请表、表单——需要被核对后变成结构化的记录。

通常由以下部件组装而成：

它是什么样子： 人们用大白话就企业内部已有的数据提出问题。

通常由以下部件组装而成：

当某个数字必须可核实时，使用上面的查询技能——它会连同答案一起返回其执行的查询语句，方便任何人事后核对这个数字。

它是什么样子： 任何人都可能从某个渠道进来——一个聊天小组件、一款消息应用、一个收件箱——构建必须先弄清楚对方是谁，才能做任何有用的事。

通常由以下部件组装而成：

它是什么样子： 一个案例需要依据规则手册进行判定，而这个判定确实需要不止一种视角——由一名主导者统筹协调多位专才。

通常由以下部件组装而成：

它是什么样子： 笔记、通话记录和消息不断涌入，需要转化为记录，再由人确认，而不是靠人手动录入。

通常由以下部件组装而成：

它是什么样子： 一份长文档——合同、协议、长篇备案文件——驱动出一条工作记录，以及一份围绕它需要发生的事项排期表。

通常由以下部件组装而成：

它是什么样子： 人们就一批文档——政策、手册、过往来往信函——提出问题。

这是唯一一种最直觉的做法往往是错误做法的形态，因此值得把它拆成两类来看：

“我该怎么做”这类是真正的搜索问题。平台自带的、针对一批文档的内置检索功能就能很好地处理，不需要在上面再搭建任何东西。
“有多少个”或“哪份文档在第几页提到了这一点”这类是计数和引证问题，最好由记录来回答，而不是靠检索。把每一页都索引为一条独立记录，再用一项查询这些记录的技能和一项对其分组汇总的技能。这样一来，计数和引证就能做到精确无误。

它是什么样子： 这类构建的重点在于展示谁可以看到什么——访问权限、脱敏和审计——而不是任何一笔具体的交易。

通常由以下部件组装而成：