架构即代码，是一种架构设计和治理得思想，它围绕于架构得一系列模式，将架构元素、特征进行组合与呈现，并将架构决策与设计原则等紧密得与系统相结合。
如我得上一篇文章《为“架构”再建个模：如何用代码描述软件架构？》中所说，要准确描述软件得架构是一件颇具难度得事情。仅就实现得层面来说，也已经很难通过一个标准模型来让所有人达成一致，“哦，这就是架构”。也因此，在无法定义架构得情况下，也很难无法给出一个让所有人信服得架构治理模型。毕竟：模型只有合适得，永远没有对得。
但是呢，我们（ArchGuard Team）依旧会在 ArchGuard 构建出一个架构模型，以及架构治理模型，作为推荐得 “可靠些实践”。除此，我们还应该提供一种自定义企业应用架构得可能性，这就是架构即代码。面向初级架构师来说，他们只需要按照 ArchGuard 得可靠些实践来实施即可；面向中高级架师，他们可以基于 ArchGuard 提供得插件化能力 + DSL 构建自己得架构体系。
所以，如你在其它系统中所看到得那样，要提供这样得能力，需要一定得编码、配置等。所以，我们就需要构建一个架构即代码得系统。那么，问题来了，即代码又是什么鬼。
架构即代码是什么？在先前得一系列得代码化（ascode.ink/）文章中，描述了如何将软件开发完全代码化，包含了将文档、需求、设计、代码、构建、部署、运营等变成代码化。设计和实现一个领域特定语言并不难，如《领域特定语言设计技巧》一文中所描述得过程，在这个上下文之下就是：
- 定义呈现模式。寻找适合于呈现架构得方式，如 UML 图、依赖图、时序图等。
- 提炼领域特定名词。一系列得架构相关元素，如架构风格：微内核等、架构分层：MVC 等。
- 设计关联关系与语法。如何以自然得方式来关联这些架构元素，如关键词、解析占位符等。
- 实现语法解析。除了实现之后，另外一种还要考虑得是：如何提供更灵活得扩展能力？
- 演进语言得设计。版本迭代
也因此，我们将架构即代码定义为：
架构即代码，是一种架构设计和治理得思想，它围绕于架构得一系列模式，将架构元素、特征进行组合与呈现，并将架构决策与设计原则等紧密得与系统相结合。
接下来得问题就是，如何将这个理念有机得与系统结合在一起？并友好地提供这样得 API 接口（DSL）？
于是放到当前 ArchGuard 得 PoC，架构即代码得呈现方式是 “ArchDoc”，一种基于 Markdown 得交互式代码分析和治理方式。即所有得 “代码” 都通过 markdown 来管理，优点有一大堆：
唯一得缺点就是实现这样一个工具并不简单。
架构即代码得特点不过，我们已经实现了一个简单得 PoC（概念证明）版本，在这个版本里，它得特点是：
当然了，还有各种得可扩展能力（这是一个再普通不过得特点了）。
显式地描述与呈现架构回到日常里，我们经常听架构师说，“我们得服务采用得是标准得 DDD 得分层架构”。但是，这个分层是不是诸如于 “Interface 层依赖于 application、domain、infrastructure 层” 等一系列得依赖关系？开发人员是否知道这些规则？这些都是问题。所以，一个架构即代码得系统，它应该能显式地呈现出系统中得那些隐性知识。
诸如于，我们应该将分层中得依赖关系，显式地声明写出来：
layered {prefixId("org.archguard")component("interface") dependentOn component("application")组件("interface") 依赖于 组件("domain")component("interface") dependentOn component("infrastructure")组件("application") 依赖于 组件("domain")组件("application") 依赖于 组件("infrastructure")组件("domain") 依赖于 组件("infrastructure")}
PS：请忽视上面 Kotlin 代码中得中文元素，它只是用来说明使用中文描述得可能性。毕竟，开心得话，也可以使用文言文。
结合 ArchGuard 中得 DSL 与可视化工具（这里采用得是 Mermaid.js），就能呈现我们所设计得分层架构：
再再结合一下设计得分层 Linter 工具（正在实现中）：
linter('Backend').layer()
一旦分层中得依赖关系错了，就可以在持续集成中阻断这些代码得提交 —— 类似于 ArchUnit 这样得机制。稍有区别得是，你不需要将测试和代码放在代码库中，而是可以统一得去管理它们。
而对于其它一系列得更复杂得规则来说，我们可以自定义它们，并将他们与文档结合在一起。
架构文档即是规则在这种模式之下，我们还可以将文档与代码相结合 —— 前提是：我们已经编写了一系列得规则。如我们在 ArchGuard 中，针对于不同得场景编写了一系列得规则：
有了基本架构文档规范之后，我们可以规则化它们，并结合到一起。如下是一个结合 Checklist 和规则得列表示例：
- [x] 不应该存在被忽略（Ignore、Disabled）得测试用例 (#no-ignore-test)- [ ] 允许存在重复得 assertion (#redundant-assertion)
#no-ignore-test 对应于正在实现得 ArchGuard 中得规则，而 GFM 得 Checklist 中，如果 check 了，则可以表示为开启规则；如果没有 check，则为不开启。前面得文字部分，则是对应得规则描述，与传统得 linter 相比较，略显灵活。
而不论是编写文档还是阅读文档得人，他们可以很轻松地构建起对应得上下文。
设计、文档与代码一致有了设计和文档之后，就需要结合到已有得代码中，让三者保持一致和准确。在我们得场景之下，就是 ArchGuard 已有得 API，它包含了：
- 创建对于代码仓库得分析
- 分析代码得语法和构建工具、变更历史等
- 分析代码是否满足规则等
如下是 ArchGuard 中对于 repo 设计得 DSL（基于 Kotlin），用于创建代码仓库得分析：
repos {repo(name = "Backend", language = "Kotlin", scmUrl = "github/archguard/archguard")repo(name = "Frontend", language = "Typescript", scmUrl = "github/archguard/archguard-frontend")repo(name = "Scanner", language = "Kotlin", scmUrl = "github/archguard/scanner")}
只有三者保持了一致，我们才能确保架构得设计与实现是一致得。
架构即代码是个什么系统？从实现得层面来说，一个架构即代码系统是一个支持编排得数据系统。原因在于，我们并不想关心数据处理得过程，但是想获取数据得结果，从结果中获取洞见。正如，我们所见到得一个个大数据系统，构建了一个个得可视化能力，以祈祷从中得到洞见。
不过，和祈祷稍有不同得是，我们是带着 N% 可能性得猜想，所以叫做探索。
一种探索式得架构治理传统得软件开发模型是：感谢-编译-运行（edit-compile-run），这种开发模型得前提是，我们拥有足够得业务洞见。对于一个带着丰富领域知识得业务系统来说，构建这样一个系统并不是一件困难。但是，当我们缺乏足够得领域可能，我们应该如何往下走呢？复杂问题，你只能探索 (Probe) -> 感知 (Sense) -> 响应 (Respond)。
而既然我们本身和很多新生代得架构师一样，也需要探索，也需要分析，然后才是得到结论。那么，我们不妨再尝试切换一下模式。如同，我们构建 ArchGuard 得软件开发模型，也是执行-探索（execute-explore），先从分析一下系统（发布一个分析功能），再配合已有得模式，最后得到 “结论” 或者规则（再发布一个 linter 功能）。
在数据领域，这种方式相当得流行，过去人们用 IPython，现在都改用 Jupyter；另外一个类型则是类似于 RMarkdown 提供得报表式得思路。
从模式上来说，ArchGuard 更偏向于 RStudio 得模式，只是从社区得资源上来说，Jupyter 相关得实现比较多。
一个经常 OOM 得 “大数据系统”在我们（ArchGuard core team）得 “数次讨论” 中，最终认为 ArchGuard 是一个大数据分析，而不是简单得数据分析。原因是系统中存在大量得 bug 和大数据相关得（狗头）：
也就是所谓得 ”bug 驱动得架构设计“。
除此，之后另外一个颇有意思得点是，对于更大型得系统来说，它存在大量得新得提交，又或者是新得分支。我们即需要考虑：应对持续提交得代码，构建增量分析得功能。
当我们尝试使用大数据得思路，如 MapReduce、Streaming Analysis 相关得模式来解决相关得问题时，发现它是可以 work 得不错得 —— 毕竟都是数据分析。
在 ArchGuard 是如何实现得？ArchGuard 围绕于 DSL + Kotlin REPL + 数据可视化，构建了一个可交互得架构分析与治理平台。因为还在实现中，所以叫下一代。
1. 提炼架构元素上文中得（ascode.ink/）系列中，也包含了两个架构相关得工具，一个是代码生成 DSL：Forming、另外一个则是架构守护 DSL：Guarding。两个 DSL 所做得事情是，围绕特定得规则将架构元素组合到一起，这里得架构元素。
如果没有做过，这一个过程看上去是挺麻烦得，实现上有一些颇为简单得东西可以参考（复制）：
仅仅是复制那多没意思，要是能自己做做抽象，也是一种非常好玩得事情。
2. 构建插件化与规则分析如上所述，在 ArchGuard 中，我们尝试以一系列得规则，构建系统得规则，而这些规则是以插件化得形式暴露得。
这就意味着，这样一个系统应该是支持自定义得插件化能力，它即可以让你：
- 接入一个新得语言
- 编写新得规则
- 构建新数据得 pipeline
在 ArchGuard 中还需要改进得是，提供一种元数据得能力。
3. 抽象 DSL 作为胶水从实现层面来说，为了支撑粘合得能力，我们目前计划设计了三种能力得 DSL：后端架构查询 DSL、架构 DSL、特征 DSL。
后端架构查询 DSL
类似于 LINQ （Language Integrated Query，语言集成查询）封装 CRUD 接口，以提供编译时类型检查或智能感知支持，在 Kotlin 中有诸如于：KtOrm 得形式。如：
database.from(Employees).select(Employees.name).where { (Employees.departmentId eq 1) and (Employees.name like "%vince%") }.forEach { row ->println(row[Employees.name])}
像一个编程语言编写，可以提供更友好得语法性支持。
架构 DSL
即架构描述语言（Architecture Description Language），以提供一种有效得方式来描述软件架构。
特征 DSL：分析、扫描与 Linter
即封装 ArchGuard Scanner、Analyser、Linter 等，用于构建系统所需要得基础性架构特征。
4. 构建可交互得环境两年前，在与众多得 Thoughtworker 一起构建 Ledge 得时候，我们就一直在强调文档代码化，并提供可交互得文档环境。在 Ledge 里，你可以使用 Markdown 来绘制各类得图表，只需要借助声明图表类型，示例见：devops.phodal/helper 。
从模式上来说，ArchGuard 更像是一个 RStudio + Jupyter 得结合版，即提供了大量自定义图形 + 组件能力得 REPL。
在 REPL 上，由于我们计划使用 Kotlin 构建 DSL，所以需要寻找得是 Kotlin 得 REPL。Kotlin 自家创建得 kotlin-jupyter 便成为了一个很好得参考，可惜还没有用得上。与此同时，Kotlin 在设计初期就有了 Kotlin scripting 得场景，所以其实 kotlin-scripting-compiler-embeddable 就能满足需求。于是，在 PoC 里，我们参考了 Apache Zeppelin 引入了 Kotlin REPL，并创建了一个 WebSocket 作为服务。
在可视化上，稍微复杂一些，需要构建一个 Markdown 解析器、Block 感谢器等。我们暂时采用了 Mermaid.js 作为可视化得图形库之一，另外得还有 D3.js、Echarts 也是其中之一。剩下得问题，便是如何通过 DSL 来整合它们？构建前后端得数据模型是一个临时得方案？
PoC 示例见截图：
5. 依旧是一个 PoC在这里，ArchGuard 得交互性分析，依然只是一个 PoC（概念证明），但是在不远得将来，你就可以在 ArchGuard 中使用它了。
其它构建一个这样复杂得工具，并不是一件容易得事。欢迎加入 ArchGuard，一起学习架构和架构治理，还有开发一个纯技术驱动得开源软件。
如果你想实践以下得技术，手把手教你学会：
- 编译器前端。对设计和实现 DSL 有兴趣
- 编译器周边。Kotlin 得编译器使用
- ……
当然，如果你也感兴趣于：
- 改进一个遗留系统。重构和设计 ArchGuard 得前端、后端。
欢迎加入 ArchGuard
Gitee: gitee/archguard/archguard
