在 ArchGuard 2023 Roadmap 里，我们计划设计一个轻量级的任务引擎。在阅读了 Gradle 源码的 Task 设计之后，我们决定改用 GitHub Action 的方式：基于 Yaml 编排任务。在设计 Runner 时，设想的场景是：：
> “所有模型都不对，但总有一些是有用的。” —— George Box
最近的项目比较忙，能腾出的业余时间不多。周内，“机缘巧合” 之下，与国内的某知名手机厂商的架构师们，一起聊了聊如何进行 Android 的架构治理，而其中的出发点是：如何从依赖治理的角度来进行 Android 的架构治理？
在编程的时候，我们会一直考虑所为的「灵活性」的问题。灵活性，可以降低我们变更的成本，减少部署的频率，进而提供更好的开发体验。而与此同时，追求实现的灵活性，可能会影响用户的体验。如何平衡这两种就是一个非常有意思的问题。
图表即代码是将图表以领域特定语言作为载体，围绕于不同的使用场景，转译生成二次产物 —— 如概念图、架构图、软件架构等。
围绕于 ArchGuard，我们一直在探索适合于大多数企业的治理模式。通常来说，对于应用架构的治理来说，我们的预期目标是，对应的架构设计（广义上的）能被采纳和遵守。如果过程中出现有流程上的问题，导致了架构在实施过程中，架构会不断偏离预期的设计。那么，我们就会致力于匹配设计相应的规范、规则和函数，来确保后续在实施过程中是能正确的落地。
多年以前，我一直对于 “专家” 这一词有大量的困惑。到底怎样才是专家？怎样才算是技术专家？社交媒体上所谓的 “技术专家”，在某方面（如编程）上的实力一般，也算是专家吗？过去，我并没有细入的思考过这个问题，直到看到一个软件的元模型，以及一本名为《表象与本质》的书，才重新构建起一个专家的雏形 —— 感谢公司大佬之前推荐的 GEB。
PS：本文只是先开个头，思考如何应对这种挑战。
领域元组件是一个包含特定领域组件（业务场景）的集合。其内部包含了一系列的组件，依赖于输入的领域元数据或者领域特定语言，构建出适用于特定领域的组件。
本文使用 Quake Web 应用编写，虽然只有基本的 Command + S 来保存标题 + 内容的功能。这个简单粗糙的页面，让我想起了多年前构建 Phodit 的场景，it works 作为开始就足够了。