读《Software Systems Architecture》（23）—— Archiving Consistency Across Views

🤔☕️🤔☕️🤔

• 读《Software Systems Architecture》（23）—— Archiving Consistency Across Views

• 📖：视图之间保持一致。

  🤔：在各自的视点，带着各自的关注，确定下技术方案，并以视图形式记录。这些文档化的视图，汇集到一起，为何要汇集到一起，顶多汇编在一起，这时候，谁会关注全部的内容？架构师得关注，毕竟这些内容由他负责，还有会关注全部内容的人，就是新加入团队的人，来的学习一下架构，那也只是概览型学习，不求甚解，只求心中有数而已，甚至看完分层视图和模块拆解视图，就心满意足翻到最后一页。既然如此，还有必要开展一致性确认嘛？原本的视图，在各自的视点下，已经沟通确认，也不会再整体汇编后，再次沟通确认。对架构师而言，每个视点内容构建时都参与，原本就已经掌握其中的每个细节。所以，并没有找到很坚定的理由来支撑，必须做好视图间一致性。这是怎么回事情？我有点困惑。

• 📖：【问题点】视图之间的结构、特性和元素，可能存在不兼容的情况。

  🤔：如果所有的视图都是一口气完成，即知道要啥，然后统一文档化，别说如果，一听就特别假，至少我个人的经验就是如此。也就是说，视图就是在一个时间轴上，架构方和关注方一起讨论确认出来。而且，这里有个非常重要的因素，就是，之所以架构参与度深，就是不确定性因素多，或者叫风险大。自然，导致视图在撰写的过程里，存在更多不确定到逐步确定的过程，因此越早期的视图，跟稍晚期的视图之间，不可避免出现越来越准确的演化路径。这么说来，到一定程度，重新同步一下所有视图，的确很有必要。

• 📖：开发，要盯着开发视图。开发视图，依赖功能视图。功能视图，扩展出运行视图和信息视图。功能视图配合用例视图，决定部署视图的样子，最终指导使用视图。

  🤔：抓住开发，反推出所有视图，这是一种事后逻辑。我更喜欢基于时间轴的逻辑。在时间发展的过程里，越来越细节化，越来越实用化，以及这一路上的各种数据产物。到了时间轴终点，再回看一下，要维护要升级，还缺点啥，补上后就很完整。

    —— By 术子米德 @2022.06.04