架构治理

中台、DDD、微服务的梦魇

2017年在YZ做数据平台的时候，有幸得到有“中台之父”之称的CTO钟老师指点，并见识了彼时软件工程界最先进的设计架构理念--中台（业务中台、数据中台、技术中台、AI中台），并免费获得了他的两本著作《企业IT架构转型之道》、《数字化转型的道与术》。

5年过去了，已不记得中台到底是什么了。但业务中台、DDD、微服务等名词深入我心；

开发团队测试、集成、联调时，有忙脚乱、团队间互相等待的场景依旧历历在目。

这段时间在SY配合IT业务团队做LTC项目中主数据子项目。也或多或少的感受到了LTC项目团队基于微服务技术架构和DDD设计理念下，项目管理、架构设计、软件开发、代码管理、测试质量、数据初始化等面临的一些问题。

• 设计与实现不匹配。设计的软件架构与真正实施后的架构，存在着巨大的差异。而这个差异，往往需要编码上线、乃至一段时间之后才能发现
• 没有规范 / 不遵守规范。作为一个资深的开发人员，我们制定了一系列的规范，但是没有多少团队人员愿意遵守
• 代码量巨大，难以识别问题。一个由十几个或者几十个微服务创建的系统，往往难以快速发现它们之间错综复杂的关系
• 架构模型的每个层级都可能出错。如服务间 API 耦合、代码间耦合、数据库耦合等等
• 架构师、开发人员自身缺乏丰富的经验。知道有问题，但是说不出来哪有问题，也不知道如何改进
• 技术债务，各种补丁和临时解决方案，各种离职或在职人员由于各种原因留下的技术问题

如何在这样的环境下，更好的让开发速度、软件质量都得到提升呢？提高项目管理水平？提高开发成员能力？引入管理平台/工具？这是一个需要持久探索的问题。

Thoughtworks 的咨询师们尝试从技术角度，解决以上问题，他们开源了架构治理平台 ArchGuard。源码地址：https://github.com/archguard/archguard.

走近ArchGuard

粗略了解了ArchGuard的愿景、功能和发展情况，也加入了开发成员微信群。总体而言，是一个比较理论化的产品。类似于Sonar，实现了一些静态代码扫描、规范检查、API列表、代码依赖分析等，对于实际开发活动帮助有多大呢？这个还要实践去检验。

但是，这个产品的想法还是吸引我的。因为我一直在思考，如何让数据开发、数据仓库ETL的SQL开发更工程化、更容易管理。了解过DataOps理念、体验过使SQL工程化的产品-DBT，使用过数据中台产品-Dataworks和数栖平台。但是，这些东西还是没有覆盖我的一些困惑：

• SQL开发时，IDE支持语法提示，具备静态类型语言的提示成熟度
• 逻辑封装，将复杂的业务规则，封装为独立的、可复用的模块
• 数据校验，支持规则式、配置化的数据单元测试及校验。
• SQL代码元分析，支持对SQL代码的语句、语义层的元信息管理
• 重复SQL代码片段识别及预警
• SQL规范检查、提示及预警

在ArchGuard提了issue，希望支持SQL的工程化管理、希望能够借鉴并集成DBT的能力、希望支持SQL方言集成插件。

当然，也希望能够支持rust。

智能的软件时代

Copilot 的出现，让人们期待软件编程时代的带来，而在这一天来临之前，我们在探索中台、探索低代码、探索无代码。 我相信，有生之年，我能够通过语音，完成ETL，完成数据建模、完成BI分析、完成数据探索。

当然，这一切，都需要一些基础技术的发展，比如AI、比如知识图谱、比如NLP。

这一天带来之前，将是程序员最美好的时代。

参考文章

https://mp.weixin.qq.com/s/mynR8fP7O7dl4yh2xnMZNg

对于文中任何疑问，欢迎加微信讨论：