23、架构文档化：从高层规划到详细设计

架构文档化：从高层规划到详细设计

1. 高层方法文档化

在进行架构设计时，首先要考虑一些关键因素并将其文档化，这些因素包括：
- 与变更相关的业务价值
- 潜在变更和影响的规模
- 过渡工作和事物处于变动状态的时间
- 为确保业务影响最小化而可以或将要采取的措施

这个阶段的目的是根据利益相关者的反馈来验证（并基于验证结果修改）规划。所以，对于反馈不要抵触，要始终认为“客户永远是对的”。即使他们在反馈中提及的技术细节或假设是错误的，他们能指出问题就说明确实存在需要关注、理解和共情的实际担忧。

审核反馈不仅是争取支持的机会，还能提高输出质量。要接受每一条反馈并采取行动。利益相关者可能会提出挑战，让你重新思考规划，指出方法的不可行性，甚至推翻关键假设，这其实是好事，因为问题迟早会出现，现在发现意味着解决起来比以后更容易。

收到反馈后，更新文档以反映所学内容。如果时间允许，将更新后的文档版本发回给利益相关者是个好做法。若因无法满足风险/经济目标或后勤原因而无法处理某条反馈，要说明原因。向利益相关者说明已考虑他们的反馈，能让他们有参与感和主人翁意识，也表明你愿意接受反馈、重视反馈并做出回应。

2. 架构定义

有了经过审核的路线图后，下一步是将其纳入架构定义文档（ADD）。ADD 不仅包含路线图中的内容，还包含更详细的技术细节。在这个层面，要详细说明过渡后事物的运行方式以及如何在时间线上实施这些变更。

根据 TOGAF，典型的 ADD 包括以下项目：
|项目|说明|
| ---- | ---- |
|范围|项目涵盖的边界|
|目标