一个架构实践的存在，是为了定义并演进它所负责的系统的架构。过去几章里，我们讨论了如何通过一套变更流程来管理系统演进：从动机出发，进入概念性方案，进而产出详细设计。在此过程中，我们说明了愿景、标准、原则、目录、术语表等如何支撑这些实践。简言之，架构实践会产出大量信息。
但如何把这些信息送达同事、合作方与其他相关人？当然，并非所有信息都该发给每个人——我们要把正确的信息给到正确的人，并且在正确的时间给到。重要更新应主动推送，其他信息则让对方按需获取。这需要大量管理。弥合信息差需要沟通，而高效的软件架构实践离不开高效的沟通实践。
书面文档为有效沟通打下基础。把内容写下来，会迫使作者与读者在思考上更清晰——这是对话与演示中常常缺失的优点。书面内容可以随时、以任意节奏被阅读；最重要的是，它是一种可扩展的投入——一千人读与一百人读，边际成本几乎无异。
然而，沟通不只等于写作。作为架构师，我们追求的沟通目标是达成共识，而共识需要对话。在对话中，信息双向流动，参与者借助这种流动发现并弥合理解鸿沟。
与此同时，“多”不等于“好”——过量沟通反而会妨碍理解：当信息组织混乱或难以检索、术语使用不一致、或新准确信息和陈旧过时信息难以区分时，问题就出现了。通过信息架构、命名规范等手段来对抗这些倾向，能进一步促进沟通与理解。
最终，是否沟通到位，要靠他人的反馈来验证。若效果不佳，你可以像迭代软件设计一样迭代沟通方式。每个人、每个团队的沟通偏好各不相同；与其死守僵化指南，不如找到最适合你团队的方法。
Mental Models（心智模型）
当人们内化某个系统的知识时，会基于对系统所体现概念的理解，构建心智模型，并用它来推理系统的行为。心智模型是人类理解世界的固有方式，并非软件所独有。
在《日常物品的设计》[10] 中，Don Norman 分享了一个关于他家冰箱心智模型的轶事。冰箱有两格：冷藏室（保鲜不结冰）与冷冻室（保持冷冻），每格都有独立温控。
在 Norman 的心智模型里，两格互相独立——控制面板看起来也没显示二者有关联。冷冻室过冷时，他就把冷冻温度往上调；他不预期这会让冷藏更冷。
不幸的是，他的心智模型与冰箱的概念模型不符。冰箱只测冷藏室温度；看似独立的“冷冻”控制，其实是调整两格之间的相对制冷配比。因此，把冷冻调“更暖”，在不调整冷藏设定的前提下，就会让冷藏更冷。
该冰箱设计的核心概念是：单一制冷源在两格间不均分配。一旦你知道“只有一个源”，就容易推理出：对“源”或“分配”的任一调整，必然同时影响两格。
幸运的是，Norman 手边有台冰箱可以试验。他先按自己的心智模型调控；不奏效后，他意识到自己的模型与冰箱的概念模型不匹配。经过一些反复试错，他弄清了运作方式，并更新了自己的理解。
在软件设计中，我们依赖沟通能力去捕捉并传达驱动系统的概念模型。与必须接受“冰箱长这样”的 Norman 不同，架构师常常在构建具体产品或能力之前就要完成这件事。这让我们更倚重通过沟通塑造共识，而非通过实验。
检验沟通是否带来理解的最佳方法是：让别人用他们的心智模型（即他们的理解）复述你描述的概念模型。若复述与最初描述一致，说明模型经受住了往返，你们达成了共识。这不是说对方背熟了一张图或一串原则——背诵≠理解。我们追求的是内化与足以等价重述的理解。
因此，一个系统的架构承载了许多概念；设计者、构建者、使用者都会基于对这些概念的理解来构建心智模型。若概念被清晰传达，各自的心智模型就会对齐，大家对系统如何运作就会有共同且正确的认识。
以我的经验，对系统概念的共享理解与一个产品团队高质量、高速度交付的能力，具有最强的相关性。这当然不保证商业成功（受多种因素影响），但当团队高度对齐时，就能高效朝共同目标前进，避免方向拉扯、决策拖沓、误入歧途——而这些问题，皆肇因于缺乏理解。
团队如何获得这种共识？凭借持续的、不中断的沟通。只有在来回对话中，我们才能检验并验证共识。达成共享心智模型，正是架构师沟通工作的目标。
Writing（写作）
沟通不止于文档，但文档仍是沟通的核心要素。基于多方面原因，我建议团队以写作为默认沟通形态，其上再叠加演示与对话。
此建议一部分源于一个朴素观察：团队成员越来越不在同一地点，甚至不在同一时区。早在新冠疫情之前，分布式团队就愈发常见，既因为公司开设多地办公室，也因为员工在家办公的增多。
事实上，尽管一些公司花费多年与大量投入，试图把员工聚在一起，但成功的反例比比皆是。比如开源项目通常难以把贡献者集中到一处：贡献者自我选择、各居其所，项目也未必有差旅预算。
多年来，开源项目一直采用所谓的“异步”沟通，本质上就是各种书面沟通：电子邮件、聊天、Issue 追踪、代码评审、Wiki，或更常见的是它们的组合。
“异步”的优势在于：沟通不必在指定的同一时间、同一地点进行。对于相差八小时以上的时区搭档，这几乎是唯一可行的方式。即便在同一时区，很多人也乐于把打断推迟到稍后处理；为完成实质工作而创造不被打扰的时间块很有帮助。
异步沟通也有难处：参与者在写作与阅读时所处的心理状态不同；这与现场对话很不一样——后者可以在交流过程中逐步建立共享上下文，从而实现快速且有效的互动。
凡是非琐碎的交流，请使用具备协作能力的工具：散文式文档可用 Wiki，代码则用代码评审系统。凡是支持行内、线程化评论的工具，都能胜任。
尽量避免用邮件与聊天处理重要内容。它们有两个问题：其一，二者都鼓励短消息；过短就会演变成冗长而混乱的来回，试图澄清原问题、理解答案，或二者兼而有之。其二，很难把回复与原文精确关联——而这正是优秀协作工具中行内评论所解决的问题。
有时你会遇到愿意写长而详邮件的人，能把问题解释得很好。内容固然好，但受众错位：邮件不可避免地只发给部分需要这信息的人。可以转发、也许能再次被找到，但这都是糟糕的信息管理方式。
经验法则：如果你正在或刚收到这样一封长邮件，把它转为文档并发送链接。文档放在哪里很关键；若放得当，日后就能轻易再找到（详见“信息架构”一节）。任何点击链接的人都会看到当前版本，而不是邮件里被冻结的历史版本；更棒的是，他们可以直接在文档上评论，让所有人看见并参与。
上述务实理由都在为写文档背书：尊重人们的地理与时间分布；促成更高质量的交流；让重要信息更易获取。但还有一个理由：写作很难。
把“难”的东西作为首选沟通方式似乎悖论，但写作之所以难，是因为：要把某件事清楚写出来，我们必须足够理解它；而要足够理解，就必须把事情想透。而把事情想透，正是我们希望架构师去做的事。
注意，我并不是在说大家都该先想透且“一次写对”再落笔分享。那会把沟通变成自我隔离，与我们的目标背道而驰。但我们也不该用毫无头绪的沟通浪费他人时间。读者可以不同意内容，但要做到这一点，首先得看得懂。我们要求的是清晰，而非正确。
事实上，自以为“一次写对”的人，往往错了。为了建立对话，作者的任务是：在当前时点，用清晰表述写下自己对议题或设计的最佳理解，以寻求反馈。他们之所以寻求反馈，是因为自己的理解尚有盲点。有用的对话始于清晰描述，引出清晰回应——这正是“开放式工作”的精髓。
书面文档也是目前可扩展性最高的沟通形式。这就是印刷术为何具有革命意义。印刷术之前也有书，但它降低了复制成本，扩大了传播范围。计算机把复制成本进一步降到几乎为零——一旦你写好文档，几乎没有任何障碍阻止它被分发给尽可能多的人。
能力越大，责任越大。若你分享的是清晰且写得好的文档，借助其广泛传播，你的项目会更进一步，产品更好、交付更快。若你分发的是写得差、让读者困惑的文档，你只是浪费了大量人力与时间。
Talking（面对面/实时交流）
尽管书面沟通至关重要，但有些场景需要实时对话。当团队尚未就系统的核心概念达成共享理解时，对话尤其有用。一旦团队定义了这些概念，它们就会成为后续工作的共同基础，甚至包括对这些概念本身的修改。然而，在此之前，要把团队“引导到第一次共同对话”并不容易。
即便在“引导阶段”，对话似乎也并非绝对必要。有时，某个个体凭借清晰的概念与出色的书面阐述，就能让一切启动起来。事实上，有些项目就是这样开始的：先有个人愿景，再有书面提案，然后才组建团队围绕其推进。
但更多时候，团队是围绕一个新挑战被召集起来的，因此第一步完全是为了形成概念，以作为起点。在这个阶段，这些概念并不需要正确、完整，甚至不必很详尽。它们最初的作用，既在于让大家对问题的理解对齐，也在于对概念性方案的对齐。
在这种“新组建团队”的情形下，对话还有一个重要的次要收益：建立团队默契。彼此不认识、不了解、不信任的人还称不上“团队”，他们只是“一群人”。把“群”变成“队”需要时间，不能操之过急，但通过实时对话，这一进程会比靠邮件和讯息更快。
对话不一定得线下见面——对一些团队而言，这也不现实。不过，在组队之初以及后续周期性地把大家实地聚在一起，是有价值的。第 9 章会更详细地讨论架构团队的这些方面。
实时对话的价值当然不止于“启动阶段”。有时，某个议题迟迟无法收敛，无论已经写了多少提案、做了多少异步评审。在截止日期逼近时，让讨论无限期拖延是不合理的。
没关系——安排一次会来解决。此时你在书面文档与异步评审上的投入就会回本：会议一开始，所有人已经对问题有充分、共同的理解。这类会议并非为了建立概念，而是为了基于这些概念解决观点分歧。一小时往往足够，而限时还能帮助大家聚焦。
迄今为止，我们讨论的是议题驱动的对话：要么源于更大的需求（如为新项目“引导”），要么专门为了值得讨论的问题而安排。这类对话遵循“好会议”的通用建议会受益良多：明确主题、提前议程，等等。
另一类会话空间则与此相反：它不是由议题驱动，而是由日程驱动。这种交流定期发生，也许每周一次；时长足够深入（至少一小时），又不会因频率而显得负担过重。
以恰当的节奏，这种方式为团队创建一个持续对话的空间。两次对话之间的间隔必须足够短，以便轻松续上话题（人人都还记得上次停在何处）；同时单次时长也要足够长，能在限定时间内取得实质进展。
这类长线对话有两个目的。其一，它们能浮现那些不够紧急（不足以单独开会）却足够重要（应当得到关注）的主题。此类主题并不总能当场解决，常需要加入待办，留待后续重访；或转化为议题驱动会议的议程项，以便投入更多时间。
其二，它们作为线下聚会的补充，让对话在两次见面之间继续推进。这里固定节奏尤为关键：既然大家都已预留时间，那么讨论那些数周或数月都未必能定论的话题也无妨。这种做法正好与“每次会议都要有议程且做决策”的传统效率观相反，但对话确实需要时间与空间。
若因任何原因无法线下相聚（比如在疫情期间），就搭建或强化一个线上交流论坛来替代。增加频率或延长时长一点都好。虽不如线下，但总比扼杀对话强得多。
无论你如何组织对话，在决定被记录、复核并以书面形式达成一致之前，任何决定都不应视为最终。跳过这一步很诱人——在当时看来，大家似乎终于完全对齐了——但跳过永远是错误。
其一，对话中的“看似对齐”可能并非真对齐：有人误解了自己的同意；有人回心转意；也可能当时有人有异议却不便开口。花时间整理并分发书面版决定；若上述问题存在，此时会浮现，你也能更早而非更晚地处理。若此阶段无异议，推进起来就更有把握。
其二，任何决定不可避免会影响到更多未参与对话的人：有人没法出席；与会者只是大团队的一个子集（不可能人人参会）；或你有新同事下周入职，需要补课。一份书面记录能让决定可追溯、可获取。
交谈自有其位：它对建立团队默契至关重要，有时也是加速攻坚的最佳选项。但它是对“写下来”的补充，而非替代。
Information Architecture（信息架构）
当团队把重心放在书面沟通上时，规模不小的项目中的架构师很快会发现自己在管理大量制品：提案、规格、标准等。架构师往往还会准备演示、通讯/简报、博客文章等较非正式的产物，以辅助沟通。
为管理这些材料投入时间很重要。缺乏策展的结果往往是一团乱麻。人们难以找到所需文档；有些人会四处打听直到找到为止——这虽然可以理解，却消耗所有人的精力。
也有人会得出“找的东西不存在”的结论。信息缺口会阻碍他们后续的设计。最好的情况是：在工作完成前，有经验的评审识别出这个缺口；最坏的情况是：重复造轮子——因为作者根本不知道系统里已经有他们需要的东西。
标准也会发生类似的失败。如果标准写了却找不着，又有何用？未遵循关键标准的代价是双重的：问题通常在非标准方案已做了一段时间后才被发现。本该加速设计与开发的标准，只有从一开始就被使用，才能发挥作用。
为了最大化这些制品的价值、并避免因组织不善而带来的失败，团队必须维护一套信息架构。信息架构是一门组织信息以便使用的学科。换言之，它规定如何、放在哪里存储这些制品，以便它们能被找到并被使用。
搭建信息架构，最好先对团队产出的文档做分类。以下是常见的类别：
- Backlog entries（待办条目） ：作为项目架构工作的待办清单（见第 4 章与第 7 章）。
- Specifications（规格/说明书） ：对各个系统要素（库、服务、应用、子系统等）的权威性描述。
- Change proposals（变更提案） ：对架构或设计的新增/删除/修改的提议；应醒目标注状态、作者、批准人。
- Standards（标准） ：规定所有架构与设计工作必须遵循的一组标准；包括所遵从的架构原则。
- Guides（指南/导引） ：对某个系统组件的概念性说明；相较高度技术化的规格，提供更易懂的解释。
- Vision papers（愿景文档） ：阐述系统或子系统在 3–5 年时间范围内的目标状态（见第 4 章）。
- Presentations（演示/报告） ：对系统（或某部分）的现场讲解或讨论的记录；保留幻灯，若可能也保留录制。
- Catalogs and dictionaries（目录与术语表） ：如第 7 章所述，目录记录软件要素与数据模型；术语表（本章稍后讨论）定义系统术语。
- Notes（笔记/札记） ：兜底类别，用于记录暂时不适合归入其他类别（如变更提案或演示）的观点/论证。
- Blog entries（博客/更新日志） ：若有广泛受众且他们需要定期更新，可选择合适载体发布；博客、邮件简报等都可以。
这些制品应按一套分类学（taxonomy）组织，以便人人能在正确的时间找到正确的材料。团队应在一个众所周知的网页上维护该分类。但你不必（也可能不愿）把所有材料都存放在同一个工具里。也许存在一个能处理待办、提案、规格、博客等的一体化工具——但我从未见过好用的。一般规律是：覆盖面越广，在具体领域的能力越妥协。所幸所有工具都支持链接，因此可以用链接把不同工具织成一个统一分类。
下面给出一个大多数项目都适用的基础分类：
-
Publications（发布物） ：首先呈现已完成、用于描述系统的文档。内部再按受众范围由广到窄组织：
- Blog entries（博客）
- Guides（指南）
- Papers（论文/白皮书）
- Specifications（规格）
- Standards（标准）
- Notes（笔记）
-
Work in progress（在制） ：其次是在制工作，用于组织项目的提案；注意还要按状态细分。“Inactive（非活动） ”指尚未获批但也未完成、暂时搁置、未来可能重启的提案。若确定不会回头，可以直接弃置。
- Active proposals（活跃提案）
- Approved proposals（已批准提案）
- Inactive proposals（非活动提案）
-
References（参考库） ：目录与术语表往后放。也适合放置公司或行业参考资料的精选清单。这里的材料常会被其他文档以链接直接引用（如指向目录/术语表条目）。
- Software catalog（软件目录）
- Data model catalog（数据模型目录）
- Dictionary（术语表）
-
Planning（规划） ：存放团队内部最相关的材料，如待办。秉持开放工作的精神，这些材料也应与其他内容一并对外可见；但多数读者并不会找它们，因此放在列表最后是合适的。
- Backlog（待办）
- Team information（团队信息）
尽管提案是架构师日常工作的核心，但组织分类时应弱化其权重。指南、论文、规格等应排在更靠前的位置——它们是多数随意访客在找的内容，而这些读者没有耐心在一堆材料里翻找。提案还应进一步按活跃/已批/非活跃细分。
对每个制品进行准确标注至关重要。首先是状态，且要醒目：草稿？评审中？最新？过期？读者最不想做的事，就是花时间读过时文档、或过早按尚未批准的提案行事，等等。
版本混淆（Version Confusion）
有一次我启动新项目时，拿到一大摞系统规格。越读越迷惑：有的子系统单看有道理，但许多似乎重复，也看不出如何拼在一起。读得越多，反而越不懂。一个月后才有人告诉我：我拿到的是两个版本的文档——“版本 1”与重写的“版本 2” ，二者毫无共同点。可惜没人把文档标注清楚它们分别对应哪个版本。
记住：组织这些材料只是工作的开始，不是结束。更新文档应成为每个条目配套清单的一部分。某个提案被批准了？把它从 Active 移到 Approved。新标准采纳了？确保它在 Publications/Standards 下发布/链接。依此类推。
若相关方可以订阅通知以获知新内容上传或被链接，记得告诉他们如何用好这个功能。我也建议每当一个提案获批、一个新规格创建、或其他重大变更发生时，写一篇博客（或等价） 。甚至可以把“写博客”纳入审批清单。
这些博客不必很长——目的只是让读者知道变更发生了。想了解细节的人，反正可以去读所引用的规格、标准或其他文档。读者会感谢你的：一两段往往比任何内置通知机制提供的信息更有用。
如果可以，收集这些材料的使用统计。全面、准确、书面的文档价值巨大：一次编写，无限复用。有些文档被查阅的频率之高，可能会让你吃惊。
反之，如果这些文档的访问量寥寥，就值得调查：是检索性有问题，大家找不到？还是文档不好用——充斥行话、过时，或其他问题？
信息像代码一样，搁着不管就会“腐坏” 。定期留出时间审视文档：它们是否在正确位置？状态是否正确？若存在明显缺口，给它加一条待办。必要时把过时文档移到归档，既保持可维护，又不妨碍日常的发现与检索。
Naming Things（命名）
当团队在塑造概念时，往往会创造大量名称。概念本身需要命名，而它们通常还包含诸多组成部件也需要命名。团队还需要给分层、模式（patterns）、组件、实体、属性、类、变量、消息、模式（schemas）等命名。你还需要为那些虽非系统本体、但对系统的创建与维护至关重要的制品、流程与工具命名。任何相对复杂的系统都需要给数百个对象命名，这些对象既有简单、离散的概念，也有包裹了几十上百个概念于单一系统组件中的术语。
请投入精力于好名字；好名字能撬动沟通的方方面面。它们促进概念模型的形成与理解；它们对书面文档至关重要——文档的读者往往无法立刻就新名词或晦涩名称发问；它们还能减少对话中鸡同鸭讲的概率。为取好名所投入的努力是值得的。
首先，也是最重要的，好名字应具描述性。如果你做了一个把实体从一种格式转换到另一种格式的服务，“Babel（巴别）”很巧妙，有人也许能懂梗；但“实体格式转换服务（Entity Format Conversion Service）”更好，因为它直接说明服务做什么，避免让读者每次遇到名字都得去记忆、推断或查找其含义。
同理，除非需要保密，别用代号。记住，代号的目的就是隐藏与混淆。把你的工作叫“X 计划”也许很酷——但结果就是没人知道你在说什么。若要保密这很好，否则对沟通而言是灾难。
也要避免仅仅聪明/花哨的名字。我曾在一个项目里使用过名为“蜉蝣（Mayfly） ”的数据迁移工具。本意是工具只“活一天”，因为蜉蝣成虫只活一两天。当然，工具后来存活更久，名字就不再合理，也与其功能无明确关联。那个团队的工程师为此解释多年。
出于同样原因，首字母缩略词应谨慎使用。它们在处理冗长名称时有帮助，但更好的做法是找到短而清晰的名称。缩略词最好别碰巧是“常见单词/人名” ，否则会削弱与其真实含义的关联。比如把“Translation for Entities Service”缩为“TEsS”——在一些地方这是一个常见女性名字——听众可能会怀疑你是在说软件，还是在说某位新同事的多语种能力。（他们也可能对大小写不一致感到恼火。）
多数系统都需要大量命名，因此应遵循一致的结构。一致结构能进一步降低认知负担。结构若组织得当，还能反映概念间的真实关系。术语与结构的一致使用会形成第二条沟通通道：通过暗含关系提供附加信息，而无需每次都显式重述。
例如，在电商系统里，每笔订单需要存两类地址：账单地址与收货地址。如果你把前者叫“Billing Address”，后者叫“Shipping Location”，这是糟糕的选择，因为它掩盖了二者同属“地址”这一内在联系；并且当你想同时指代它们时也会麻烦——合起来到底叫地址、位置，还是“地址与位置”？
更好的做法是采用一种结构：Billing Address（账单地址） 、Shipping Address（收货地址） 、Address（地址） 。这些名字不花哨，但描述准确、信息丰富，且单独/合在一起都不言自明。
上例中的结构既直观又有力：为核心概念使用一个简单名（此处为 Address），对相关概念通过形容词修饰来命名（Billing、Shipping）。这种命名结构很常见，只是人们常常不自觉。
该结构也容易扩展。例如：客户在更新Billing Address（账单地址） ？那他们是在用New Billing Address（新账单地址）替换Old Billing Address（旧账单地址） 。你随时可以再加一个形容词作前缀来消歧。
还可以加名词后缀。地址是否存放在一个独立服务里？那么你可能会说：Address Entities（地址实体）存放在Address Service（地址服务）中，并通过一次Address Update（地址更新）来修改。它的工作方式写在Address Service Specification（地址服务规格）里。当名称之间的联系显而易见且易记时，你会减少大量“解释关系”的时间。
一致性应尽可能推广。许多系统会为每个实体记录基本元数据：创建时间、最后更新时间等。这些属性应在任何地方都用相同的名字，且采用相同的形式：比如“created / modified”是好搭档；“createDate / modificationTime”就不一致。无论在命名还是使用阶段，选定一种形式并坚持下去都能省去大量麻烦。若能采用相关标准中的约定，节省的时间更多，也避免了团队自行对齐规则的成本。
若确需改名，请全面改。选择一个好名字优于继续使用误导性名称；而新旧并行更糟。因此，一旦改名，就必须把变更应用到现有的规格、标准与其他受影响文档上。
改名很适合作为“把变更提案当作补丁（patch） ”的隐喻。变更提案会同时使用新旧名并解释改名的理由，充当两者之间的链接。一旦批准，这个“补丁”就要应用到所有使用旧术语的文档上。（注意：历史变更提案不应被修改。）若改名做得好，新成员无需知道曾经的旧名也能正常工作。
最后，改名之后，要督促大家在口头与书面中都使用新名。在切换期纠正别人或被纠正会有些尴尬，但为了巩固新名称的使用，这通常是必要的；否则对旧术语的继续使用会被视为对其继续沿用的默许。
Dictionaries（术语表 / 词汇表）
一致、具描述性的命名当然重要，也应有清晰、简练的定义作支撑。为每个术语写一条定义有两重作用：其一，作为权威参照以防出现歧义或误解；其二，更重要的是，它迫使概念澄清。我不止一次见过团队在给自以为早已理解的术语写定义时卡壳。
最理想的是把术语表织入你的文档体系。无论你把系统文档放在哪里，每条定义都应有一个唯一 URL，便于其他文档链接。例如：Wiki 的独立页面很合适；表格的一行则不太适合。若能做到，尽量复用你维护变更提案、规格或其他制品所使用的同类工具。
每份文档在术语首次出现时都应链接到术语表。对同一文档中的后续出现无需再反复加链接——这会增加作者负担而无实质价值；而且由于链接常以版式差异呈现，过多链接也会让读者疲劳。
尽管许多规格模板里常见“术语（Terminology） ”一节，但一般而言单个文档不应自带这部分。若包含，要么是在重复术语表内容（不如链接），要么是给出不同定义（制造混乱）。仅在文档使用了系统术语表覆盖范围之外的术语，或变更提案引入了新术语时才应例外。
谈到“范围”，请避免重定义已有标准定义的术语。若行业标准已有定义，链接到标准即可。这样能节省你复述定义的时间，也能强化与标准的关联；同时，新加入者可借助其行业知识更快上手你的系统。
作为作者，若你准备给某个术语加链接却发现术语表中没有对应条目，请停下来先补一条。一开始这样做会让人觉得“麻烦”，但当有了一套良好的定义集后，这种情况会显著减少。而且，系统文档需要引用的定义集合，正是术语表应包含什么的最佳量化指标。
变更提案是上述规则的必要例外。写变更提案时，你是在提出新东西；在获批前，它还不是系统的一部分。若变更涉及定义新术语，则这些条目在变更获批之前不得加入术语表。因此，变更提案内部应包含其全部新术语的定义。获批之后，这些定义再迁入术语表，由术语表成为权威来源。
随着项目术语表的扩充，你需要对其组织。我建议为条目建立分类体系并打标签。例如，可按其与系统/领域/分层/服务/数据模型的关系来打标签。选择维护工具时，关注它是否支持打标签与按标签生成列表，并为每个条目提供唯一 URL。
术语表条目也是文档（只是更小），应有自己的模板。建议包含以下部分：
- Excerpt（摘录） ：一句话定义，可在其他上下文中直接引用。
- Detail（详解） ：对摘录的扩展说明。
- See also（参见） ：相关术语或术语列表。
- References（参考） ：与该术语直接相关的规格或其他文档的链接。
最后，务必为定义中的其他术语添加链接。这会很常见——仅在“摘录”里就出现两三个链接也不罕见。构建这些定义与链接需要时间，但一旦建立起来，你会惊讶于仅凭在术语表中穿梭就能对系统了解大幅加深。
Listening（倾听）
就像只有在客户作出反应后，我们才知道产品是否击中了要害；同样，只有在听到交流对象的反馈后，我们才知道自己的沟通是否有效。我们可以为他们写作、与他们交谈，可以组织、命名并定义我们所写所谈之物。但在对方真正理解我们传达的内容之前，我们仍未命中目标。
要知道自己是否被理解，首先必须倾听。当他人反馈给我们的内容与我们所持的同一套概念模型一致时，才表明我们达成了共同理解。
倾听并不只在对方开口时才发生。若你的架构团队与工程、产品管理或其他撰写自己设计、规格与文档的团队合作，那么“倾听”他们的声音就意味着要评审他们的文档——注意，这里是评审，不只是阅读。人很容易在“看过”一份文档的同时并未真正理解它。若你在阅读过程中没有产生留下一两条评论的冲动，说明你可能还不够专注于文档真正要表达的内容。
这并不意味着每位架构师都要读所有其他团队产出的所有文档。多数时候那并不现实。正如系统设计与治理是团队协作一样，管理外部输入也需要团队协作。为每份文档记录“谁应当阅读、谁已经阅读”很有帮助。此处再次需要良好的信息架构来组织文档，并清晰呈现其状态与相关性。
如果你的团队在沟通实践上树立了良好示范，你会发现其他团队可能会采纳类似做法：使用相近的模板、以相似方式组织信息、向术语表贡献定义。若看到你的最佳实践被借鉴，不妨花点时间鼓励这种行为。流程与结构的对齐能为达成共同理解提供更宽的基础。
第二个好处在于：团队之间相互借鉴并改进实践。若别的团队采用你的模板并做了修改，看看他们改了什么——也许他们找到了同样适用于你们的改进点。花时间去审视这些变化、思考其意义并吸收经验，本身就是在倾听同事。共享这些改进能让所有人受益，也有助于营造良好的工作氛围。
最佳结果往往出现在各个职能融合其沟通结构之时。这并不意味着“架构文档”和“需求文档”会变成一回事——流程中的各步骤仍需分开。但概念模型、信息架构、命名等，属于产品（乃至产品族）的共性，不限于软件架构。若能在跨职能层面对齐它们，就为把共同理解扩展到新工作打下了最坚实的基础。
良好沟通还需要谦逊。我们自然会为自己的工作感到自豪。向他人解释完自己的工作后，无论媒介为何，人们很容易把“核实理解的倾听”混淆成“寻求认可的倾听”。我们都希望得到认可，但认可并不等同于理解。
反过来，理解就是一种认可——即便它看起来不像。你也许经历过这样的时刻：有人在你面前讲述你的工作，而他并不知道你早已熟悉相关内容、且从未直接向他讲过。起初这可能令人沮丧，因为没有明示你的贡献。
但这其实是个了不起的时刻：一个未曾与你当面交流过的人，能够把你的思路清晰地复现到让你一听就知道“这是我的工作”。这无疑说明沟通非常有效。与其在“谁该获功劳”上纠结，不如默默欣赏成果与沟通本身的成功。
Summary（小结）
产品开发是团队协作的成果，而没有有效沟通就没有团队的运转。最具生产力的团队，都建立在共享的概念模型之上，并通过书面与口头沟通去建立、维持并演化这种理解。
沟通应强调书面文档：写作为跨地域与跨时区协作提供便利，具备持久性与可扩展性，还能迫使思考清晰。用文档捕捉那些原本会被埋没在邮件或聊天中的信息。
用留出对话的时间与空间来补充写作。较长的线下会议对建立新概念与培养团队默契尤其有帮助。临时对话可用于解决误解与其他顾虑。定期安排（如例会）既能兜底零散议题，也能在时间维度上维系团队连接。
项目会产生大量文档。请为信息架构投入精力，使所有人（不仅是架构师）都能找到所需文档。让沟通成为反馈通道，以持续改进你的工作。
在沟通时，谨慎命名：坚持清晰、具描述性的名称与一致的命名模式；把这些名称文档化并一致使用；维护一份项目术语表，收录这些名称及其他重要术语。这些努力既能提升你自身思维的清晰度，也能促进更广泛团队的沟通。
所有团队都在沟通上投入时间与精力。以结构化的文档、信息架构与命名为抓手，团队会发现这些投入能帮助他们更高效、更有成效地开展工作。
