构建一个架构工作台并不是一件容易的事，涉及到了一系列的编译器相关的知识，编辑器相关的知识，当然还有其核心的架构相关的知识。
架构工作台是一个环境，其设计初衷用于帮助人们设计架构、演进架构、观测架构，并有效地运用架构所需要的高质量工具，如交互式的架构开发和分析。
架构即代码，是一种架构设计和治理的思想，它围绕于架构的一系列模式，将架构元素、特征进行组合与呈现，并将架构决策与设计原则等紧密的与系统相结合。
在上一篇文章《“分布式” 开发规范治理》中，我们谈论到了 “分布式” 场景下，对于架构治理和规范治理的一系列问题。在那篇文章里，我们提及了一系列的工具，如 API Linter 工具 Spectral，数据库 Linter 工具 SQLFluff。而为了在 ArchGuard 中完善分布式规范的能力，便分析了几个现有的工具。
在架构治理平台 ArchGuard 中，为了实现对架构的治理，我们需要代码 + 模型描述所要处理的内容和数据。所以，在 ArchGuard 中，我们有了代码的模型、依赖的模型、变更的模型等，剩下的两个核心的部分就是架构的模型、架构的治理模型，其它的还有诸如构建的模型等，会在后续的过程中持续引入到系统中。
多年以前，我一直对于 “专家” 这一词有大量的困惑。到底怎样才是专家？怎样才算是技术专家？社交媒体上所谓的 “技术专家”，在某方面（如编程）上的实力一般，也算是专家吗？过去，我并没有细入的思考过这个问题，直到看到一个软件的元模型，以及一本名为《表象与本质》的书，才重新构建起一个专家的雏形 —— 感谢公司大佬之前推荐的 GEB。
Arduino 是一个开源嵌入式软硬件平台。如果你看过我写的《自己动手设计物联网》，又或者是和大学同学翻译的《Arduino 编程:实现梦想的工具和技术》，那么对于些，你应该是有些体会的：Arduino 是一个非常有意思的组合式软件 + 硬件平台。
PS：本文只是先开个头，思考如何应对这种挑战。
这个月，我和我的同事们开源了一个内部的架构治理平台：ArchGuard，我们进行了一系列的遗留系统的迁移工作：
遗留系统的现代化演进是一门艺术。