我们学习到的某一个领域的知识，很少会孤立存在的。当我们有意识地去发掘的时候，便会惊讶地发现：它们之间存在联系。这也就是我写这一篇文章的目的，尝试去建立对于思维图形化的推理过程。显然，与结果相比，过程也许是这篇文章的一个重点。
最近几年，随着技术产品化的流行，越来越多的公司（如云厂商、开源软件公司）将软件提供给市场，2D（to Developer）成为了一种炙手可热的商业 “风口”。所以，我们会看到各种面向开发者的网站以及各类的服务。
PS：一篇纯吐槽而主的文章，请不要过分代入。
架构自治服务是一种面向架构分析领域的数据自助服务。它提供了一种集成一体的数据分析方案，让开发人员、架构师、管理者等可以根据不同任务，自由搭配、组合出适用于自身洞察需求的任务/函数。
围绕于 ArchGuard，我们一直在探索适合于大多数企业的治理模式。通常来说，对于应用架构的治理来说，我们的预期目标是，对应的架构设计（广义上的）能被采纳和遵守。如果过程中出现有流程上的问题，导致了架构在实施过程中，架构会不断偏离预期的设计。那么，我们就会致力于匹配设计相应的规范、规则和函数，来确保后续在实施过程中是能正确的落地。
构建一个架构工作台并不是一件容易的事，涉及到了一系列的编译器相关的知识，编辑器相关的知识，当然还有其核心的架构相关的知识。
架构工作台是一个环境，其设计初衷用于帮助人们设计架构、演进架构、观测架构，并有效地运用架构所需要的高质量工具，如交互式的架构开发和分析。
架构即代码，是一种架构设计和治理的思想，它围绕于架构的一系列模式，将架构元素、特征进行组合与呈现，并将架构决策与设计原则等紧密的与系统相结合。
在上一篇文章《“分布式” 开发规范治理》中，我们谈论到了 “分布式” 场景下，对于架构治理和规范治理的一系列问题。在那篇文章里，我们提及了一系列的工具，如 API Linter 工具 Spectral，数据库 Linter 工具 SQLFluff。而为了在 ArchGuard 中完善分布式规范的能力，便分析了几个现有的工具。
在架构治理平台 ArchGuard 中，为了实现对架构的治理，我们需要代码 + 模型描述所要处理的内容和数据。所以，在 ArchGuard 中，我们有了代码的模型、依赖的模型、变更的模型等，剩下的两个核心的部分就是架构的模型、架构的治理模型，其它的还有诸如构建的模型等，会在后续的过程中持续引入到系统中。