架构工作台是一个环境,其设计初衷用于帮助人们设计架构、演进架构、观测架构,并有效地运用架构所需要的高质量工具,如交互式的架构开发和分析。 在上一篇文章《架构即代码:编码下一代企业(应用)架构体系》中,我们介绍了架构即代码的思想,它是如何围绕于架构的一系列模式,将架构元素、特征进行组合与呈现,并将架构决策与设计原则等紧密的与系统相结合。 而为了实施及落地架构即代码的理念,还需要构建一个运行这些代码的平台,我们称它称为架构工作台。可是,为什么我们要构建一个架构工作台?仅仅是为了好玩。 为什么构建架构工作台? 在 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
多年以前,我一直对于 “专家” 这一词有大量的困惑。到底怎样才是专家?怎样才算是技术专家?社交媒体上所谓的 “技术专家”,在某方面(如编程)上的实力一般,也算是专家吗?过去,我并没有细入的思考过这个问题,直到看到一个软件的元模型,以及一本名为《表象与本质》的书,才重新构建起一个专家的雏形 —— 感谢公司大佬之前推荐的 GEB。 在这里,便尝试性地做出第一次小结。作为第一次小结,它会存在一系列的不完善的地方,有待于后续进行完善。 所谓的专家嘛,就是在擅长的 “领域”(或者领域中的一个子领域)里,构建了具有范畴化(归类)的概念空间,并可以通过类比灵活地完善自己的概念库。简单来说,就是一个专家能有不同层次的抽象能力,还能以合理的方式(不同的层次)的语言和不同的人进行 “交流”(编程的对话)。...
Apr 2022
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
遗留系统的现代化演进是一门艺术。 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
Follow RSS Feeds, Blogs, Podcasts, Twitter searches, Facebook pages, even Email Newsletters! Get unfiltered news feeds or filter them to your liking.
Get Inoreader