架构工作台：构建企业（应用）架构的数字孪生

架构工作台是一个环境，其设计初衷用于帮助人们设计架构、演进架构、观测架构，并有效地运用架构所需要的高质量工具，如交互式的架构开发和分析。 在上一篇文章《架构即代码：编码下一代企业（应用）架构体系》中，我们介绍了架构即代码的思想，它是如何围绕于架构的一系列模式，将架构元素、特征进行组合与呈现，并将架构决策与设计原则等紧密的与系统相结合。 而为了实施及落地架构即代码的理念，还需要构建一个运行这些代码的平台，我们称它称为架构工作台。可是，为什么我们要构建一个架构工作台？仅仅是为了好玩。 为什么构建架构工作台？ 在 ArchGuard 中，我们想治理的是架构的三种形态：设计态、开发态和运行态。对应于： 设计新的企业（应用）架构。诸如于描述和设计系统的当前架构。 理解和管控系统的现状。诸如于通过可视化的手段展示系统的现状、以规则来管理系统。...

6d

架构即代码：编码下一代企业（应用）架构体系

架构即代码，是一种架构设计和治理的思想，它围绕于架构的一系列模式，将架构元素、特征进行组合与呈现，并将架构决策与设计原则等紧密的与系统相结合。 如我的上一篇文章《为“架构”再建个模：如何用代码描述软件架构？》中所说，要准确描述软件的架构是一件颇具难度的事情。仅就实现的层面来说，也已经很难通过一个标准模型来让所有人达成一致，“哦，这就是架构”。也因此，在无法定义架构的情况下，也很难无法给出一个让所有人信服的架构治理模型。毕竟：模型只有合适的，永远没有对的。 但是呢，我们（ArchGuard Team）依旧会在 ArchGuard 构建出一个架构模型，以及架构治理模型，作为推荐的 “最佳实践”。除此，我们还应该提供一种自定义企业应用架构的可能性，这就是架构即代码。面向初级架构师来说，他们只需要按照...

2w

架构治理调研：规则、表达式还有语言

在上一篇文章《“分布式” 开发规范治理》中，我们谈论到了 “分布式” 场景下，对于架构治理和规范治理的一系列问题。在那篇文章里，我们提及了一系列的工具，如 API Linter 工具 Spectral，数据库 Linter 工具 SQLFluff。而为了在 ArchGuard 中完善分布式规范的能力，便分析了几个现有的工具。 对于我们来说，构建一个类似的工具，需要考虑的一些因素有： 插件化。开发人员可以根据已有的守护规则，开发一些新的架构守护规则，如针对于 API 的，针对于数据库调用链路的。 可测试性。如果采用的是完全 DSL 或者 半 DSL，那么如何让后续的 语言无关。如何不绑定于语言的语法树，而实现对于多种语言的支持。 出于这个目的，只好拿起现有的代码进行一番分析，主要有四个工具，适用于...

3w

为“架构”再建个模：如何用代码描述软件架构？

在架构治理平台 ArchGuard 中，为了实现对架构的治理，我们需要代码 + 模型描述所要处理的内容和数据。所以，在 ArchGuard 中，我们有了代码的模型、依赖的模型、变更的模型等，剩下的两个核心的部分就是架构的模型、架构的治理模型，其它的还有诸如构建的模型等，会在后续的过程中持续引入到系统中。 PS：本文里的架构展开是基于自动化分析需求的，模型也是基于这个动机出发的。 架构是什么？？ 对单个语言的代码建模并不难，对于一个语言有特别的概念，如 package、class、field、function 等等。在有了明确概念的基础之下，结合我们的业务上的需求，就能构建一个太差不差的模型。在采用 DDD 这一类建模方式的时候，产生共识，提炼知识，形成概念等，便能构建出模型的雏形。 起点：架构是重要的元素...

4w

专家 x 抽象 x 类比

多年以前，我一直对于 “专家” 这一词有大量的困惑。到底怎样才是专家？怎样才算是技术专家？社交媒体上所谓的 “技术专家”，在某方面（如编程）上的实力一般，也算是专家吗？过去，我并没有细入的思考过这个问题，直到看到一个软件的元模型，以及一本名为《表象与本质》的书，才重新构建起一个专家的雏形 —— 感谢公司大佬之前推荐的 GEB。 在这里，便尝试性地做出第一次小结。作为第一次小结，它会存在一系列的不完善的地方，有待于后续进行完善。 所谓的专家嘛，就是在擅长的 “领域”（或者领域中的一个子领域）里，构建了具有范畴化（归类）的概念空间，并可以通过类比灵活地完善自己的概念库。简单来说，就是一个专家能有不同层次的抽象能力，还能以合理的方式（不同的层次）的语言和不同的人进行 “交流”（编程的对话）。...

Apr 2022

组合架构：Arduino 浅析

Arduino 是一个开源嵌入式软硬件平台。如果你看过我写的《自己动手设计物联网》，又或者是和大学同学翻译的《Arduino 编程:实现梦想的工具和技术》，那么对于些，你应该是有些体会的：Arduino 是一个非常有意思的组合式软件 + 硬件平台。 一套代码多处运行：Arduino Arduino 的有意思之处在于，它的软件和硬件都是开源的，并且都能以模块化的形式组装： 在硬件上，模块化的形式是可组装（叠加上去）的开发板、扩展板。 在软件上，模块化的形式是可调用的软件库。 在生态上，模块化的形式是开源共创。即通过开放的方式，建立硬件的模块化，建立软件的模块化。 在设计上， 模块化的形式是标准化，通过标准化的形式 从技术能力上来说，我们编写的 Arduino 代码，只需要配置一下不同的...

Mar 2022

“分布式” 开发规范治理

PS：本文只是先开个头，思考如何应对这种挑战。 如果只是从系统来考虑，标题里虽然说的是 “分布式” 规范治理，但是更多的时候是指多仓库的规范治理。而多仓库本身也充斥着一些不合理性，诸如于一个代码仓库内，可能包含着多个模块，如 monorepo。从这个角度来看，只是讨论分布式系统，可能有一些单薄。但是呢，我们在写规范，针对的是系统吗？难道不是团队中的开发人员？所以，我们所想的治理的是分布式协作的规范性问题。 回顾开发规范及其工具化 对于软件研发来说，效能的提升是一个非常宏大的史诗级话题，在这个话题里，规范的建立是一个非常有效的方案 —— 当且仅当，我们建立了配套的相关执行机制和工具。在确保了拥有统一规范的情况下，A 团队的开发人员，可以快速地到 B 团队开发，而不需要一些额外的讨论。简单来说，规范就是一种用于规模化提升效能的模式。...

Mar 2022

回到单体架构：一个开源项目的重构

这个月，我和我的同事们开源了一个内部的架构治理平台：ArchGuard，我们进行了一系列的遗留系统的迁移工作： 从 Maven 到 Gradle。原因是灵活的自定义 task，还有自带的增量构建等。 依赖库的更新。 系统从微服务到单体。 构建规范和对应的规范工具化 持续交付。结合 GitHub Action、Docker Hub 等一系列的 DevOps 开源基础设施，进行全自动化的构建。 …… 其中，最有意思的一个故事莫过于：从微服务到单体架构。因为，它是一种反主流的形式，又或者是反主流的技术架构。 遗留微服务系统的挑战 在我们经过了一系列的内部会议之后，决定了将 ArchGuard 开源。随后，看到了代码库，我们发现了一系列的挑战： 过多的服务/模块。这个在内部开发多年的系统，由多个微服务组成...

Feb 2022

遗留系统现代化工具集：Modernizing

遗留系统的现代化演进是一门艺术。 Why 开源 + 遗留系统现代化工具 在日常的软件开发里，我们经常会遇到一系列的问题，诸如于： 如何解决人类智商不够的问题？模式、原则和工具 谁应该去解决代码的问题？代码 …… 应对于这些问题，其中的一个解决方案就是：自动化的工具，有些人喜欢称之为器。支撑这些工具的便是一系列的原则与模式，将它们融入到工具之中。另外一个解决人成长的方案就是：元元（meta-meta），这是另外一个故事。 遗留系统是常态。在咨询团队里，我们所遇到的系统里多数是是遗留系统，来到一个新项目时，可能就需要对他们快速的分析，以提供洞见 —— 写 PPT 汇报。所以，在过去的几年里，咨询团队也沉淀了一系列的遗留系统分析和重构的工具，比如新哥的 Tequila、正在开源的架构分析和守护工具...

Feb 2022

数据处理的抽象：数据与知识处理的思考

PS：这是一篇思考 + 笔记的整理。 过去的两个月里，在业余时间里，我一直在设计 Quake（https://github.com/phodal/quake），一个我称之为知识管理元框架的工具。Quake 除了是一个知识管理工具，它还包含了我对于数据处理的一系列想法： 外部 DSL 描述数据流。在数据领域里，诸如于 Presto 这样的 SQL on Everything 框架就是一个不错的示例。 数据源的抽象与类型系统：。对于元数据库来说，Apache Atlas 这样的抽象，也提供了一个非常好的思路。 数据与行为抽象的低代码。 类型流 Typeflow 在这方面提供了我在这方面的灵感。 端到端的自定义 BI。在 BI 领域里的 Tableau 和 Superset 也是非常不错的一个参考。...

Feb 2022