Blog
Blog
PHODAL

查看分类 架构

在 ArchGuard 2023 Roadmap 里,我们计划设计一个轻量级的任务引擎。在阅读了 Gradle 源码的 Task 设计之后,我们决定改用 GitHub Action 的方式:基于 Yaml 编排任务。在设计 Runner 时,设想的场景是::

> “所有模型都不对,但总有一些是有用的。” —— George Box

最近的项目比较忙,能腾出的业余时间不多。周内,“机缘巧合” 之下,与国内的某知名手机厂商的架构师们,一起聊了聊如何进行 Android 的架构治理,而其中的出发点是:如何从依赖治理的角度来进行 Android 的架构治理?

在编程的时候,我们会一直考虑所为的「灵活性」的问题。灵活性,可以降低我们变更的成本,减少部署的频率,进而提供更好的开发体验。而与此同时,追求实现的灵活性,可能会影响用户的体验。如何平衡这两种就是一个非常有意思的问题。

图表即代码是将图表以领域特定语言作为载体,围绕于不同的使用场景,转译生成二次产物 —— 如概念图、架构图、软件架构等。

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

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

PS:本文只是先开个头,思考如何应对这种挑战。

领域元组件是一个包含特定领域组件(业务场景)的集合。其内部包含了一系列的组件,依赖于输入的领域元数据或者领域特定语言,构建出适用于特定领域的组件。

本文使用 Quake Web 应用编写,虽然只有基本的 Command + S 来保存标题 + 内容的功能。这个简单粗糙的页面,让我想起了多年前构建 Phodit 的场景,it works 作为开始就足够了。

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Engineer, Consultant, Writer, Designer

ThoughtWorks 技术专家

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

开源深度爱好者

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

联系我: h@phodal.com

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

存档

分类

标签

作者