Blog
Blog
PHODAL

最近几年,随着技术产品化的流行,越来越多的公司(如云厂商、开源软件公司)将软件提供给市场,2D(to Developer)成为了一种炙手可热的商业 “风口”。所以,我们会看到各种面向开发者的网站以及各类的服务。

PS:一篇纯吐槽而主的文章,请不要过分代入。

架构自治服务是一种面向架构分析领域的数据自助服务。它提供了一种集成一体的数据分析方案,让开发人员、架构师、管理者等可以根据不同任务,自由搭配、组合出适用于自身洞察需求的任务/函数。

围绕于 ArchGuard,我们一直在探索适合于大多数企业的治理模式。通常来说,对于应用架构的治理来说,我们的预期目标是,对应的架构设计(广义上的)能被采纳和遵守。如果过程中出现有流程上的问题,导致了架构在实施过程中,架构会不断偏离预期的设计。那么,我们就会致力于匹配设计相应的规范、规则和函数,来确保后续在实施过程中是能正确的落地。

构建一个架构工作台并不是一件容易的事,涉及到了一系列的编译器相关的知识,编辑器相关的知识,当然还有其核心的架构相关的知识。

架构工作台是一个环境,其设计初衷用于帮助人们设计架构、演进架构、观测架构,并有效地运用架构所需要的高质量工具,如交互式的架构开发和分析。

架构即代码,是一种架构设计和治理的思想,它围绕于架构的一系列模式,将架构元素、特征进行组合与呈现,并将架构决策与设计原则等紧密的与系统相结合。

在上一篇文章《“分布式” 开发规范治理》中,我们谈论到了 “分布式” 场景下,对于架构治理和规范治理的一系列问题。在那篇文章里,我们提及了一系列的工具,如 API Linter 工具 Spectral,数据库 Linter 工具 SQLFluff。而为了在 ArchGuard 中完善分布式规范的能力,便分析了几个现有的工具。

在架构治理平台 ArchGuard 中,为了实现对架构的治理,我们需要代码 + 模型描述所要处理的内容和数据。所以,在 ArchGuard 中,我们有了代码的模型、依赖的模型、变更的模型等,剩下的两个核心的部分就是架构的模型、架构的治理模型,其它的还有诸如构建的模型等,会在后续的过程中持续引入到系统中。

多年以前,我一直对于 “专家” 这一词有大量的困惑。到底怎样才是专家?怎样才算是技术专家?社交媒体上所谓的 “技术专家”,在某方面(如编程)上的实力一般,也算是专家吗?过去,我并没有细入的思考过这个问题,直到看到一个软件的元模型,以及一本名为《表象与本质》的书,才重新构建起一个专家的雏形 —— 感谢公司大佬之前推荐的 GEB。

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Engineer, Consultant, Writer, Designer

ThoughtWorks 技术专家

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 最新技术分享

存档

分类

标签

作者