为什么构建架构工作台?
在 ArchGuard 中,我们想治理的是架构的三种形态:设计态、开发态和运行态。对应于:
设计新的企业(应用)架构。诸如于描述和设计系统的当前架构。
理解和管控系统的现状。诸如于通过可视化的手段展示系统的现状、以规则来管理系统。
观测系统 <=> 架构的运行。
同样,对于诸多中大型组织师的架构相关的部门来说,他们同样存在上述的这些问题。并且,我相信他们也面临着同我们构建 ArchGuard 时一样的困境:
架构是多维的。包含技术、数据、安全、运维与系统等
缺乏统一的架构语言。用于沟通的人类语言,诸如于什么是组件?
系统的架构千奇百怪。架构风格或模式差异,如微服务架构、插件化架构等。
缺乏业务上下文。作为一个外部架构师,帮助治理时缺乏一些上下文。
细节是魔鬼。架构的世界丰富多彩,没有办法一一展现出来,比如一个小小的接口,可能会反转我们对于理解的假设。
我们(ArchGuard 团队)目前的架构能力有限(这个不会写出来的)—— 资深架构师太少。
所以,在实现这样一个标准化的架构模式系统之前,不如尝试构建一个更灵活的形式:架构工作台。它可以帮助我们更好地探索系统,也更符合我们的初期体验。
什么是架构工作台
对于工作台这一概念来说,作为一个活跃的 DSL 创造者,我比较熟悉的是 Martin Fowler 在《领域特定语言》中对于语言工作台的定义:
语言工作台是一个环境,其设计初衷就是帮助人们构建新的 DSL,以及有效地运用这些 DSL 所需的高质量工具。
也因此在定