跳到主要内容

为什么要开发EventMatrix

· 阅读需 18 分钟
Garrick
Garrick
全栈开发

不断狂奔的 AI 技术正在改变一切，包括软件开发，可以肯定的是，未来的程序员能且只能拥抱 AI，从 CRUD 囚徒到 AI 指挥官，一个程序员 10 年抗争的技术觉悟，EventMatrix 尝试走出一条面向后端开发的新范式

为什么要开发 EventMatrix？​

当记不起第几次为新项目搭建用户权限系统时，当凌晨还在写增删改查时，当不同团队重复开发相同接口却无法复用时，不止一次问过自己这种开发模式什么时候是个头，什么时候这种传统呆板的开发模式能被淘汰？

2020 年首次接触 DDD，就像在代码迷雾和繁重的工程任务中看到了灯塔，但当我试图基于 DDD 思想用 Java 构建一款能解决业务解耦、摆脱技术债务的理想框架时，却发现自己像在造一艘"代码航母"，本已繁重的 Spring 生态加上 DDD 定义和各种微服务组件的架构复杂度，与现有的微服务架构并无太大本质差别，最终让这种理想主义尝试搁浅在臃肿架构的沙滩上。

转机出现在后来对 Go 的深入学习中，一方面 Go 领域没有 spring 这种重量级标准化框架代入的思想枷锁，另一方面 Go 的高性能低内存占用、二进制程序无依赖发布等特性，让我再次燃起想用 Go 来做一款面向业务解耦、摆脱纯技术思维开发框架的念头；更重要的是，GPT-3.5 的横空出世像一记惊雷，当 AI 能 2、3 分钟生成一个小模块可用的代码时，感觉真正终结传统开发模式的时代要来了。

EventMatrix 正是在这样的时代变革中应运而生。它不仅是对传统开发模式的告别，也是面向 AI 时代的开发探索的尝试：

  • 当你的竞争对手用 AI 生成 80%的模板代码时，你还在手写 CRUD 代码？
  • 当业务方要求 3 天上线新功能时，你还在争论接口规范？
  • 当需要将单体应用拆分为微服务时，你还在为如何拆分接口而苦恼纠结？

EventMatrix 的诞生，源于一个朴素的愿景：让开发者摆脱大量重复性编码束缚，更关注业务逻辑的实现，甚至在业务层面上避免重复造轮子。可以预见的未来 AI 编码能力只会越来越强，希望能像自动驾驶解放司机那样，EventMatrix 能解放在 CRUD 泥潭中挣扎的开发者，让更多的技术思考时间回归业务价值本身。

一、CRUD 困局何时休？3 大创新解法告别 996​

回想过往传统开发中，过半的时间消耗在 CRUD（增删查改）、参数校验等机械性编码上，参与过的几十个项目中，不管是 JAVA、Python、 Nodejs 还是 Go，每次新项目都要从用户管理，权限管理，常量管理到业务模块，重复编写数据访问层、参数校验、接口文档、权限管理等模板代码，如果团队人数够大或分组多，还容易出现不同团队各自实现同一相似接口等问题。

EventMatrix 引入新机制破解困局：

  1. 标准化事件驱动业务：将业务操作抽象成统一格式的事件，并将规范设计为实际上的标准，只能通过管理后台统一配置和管理，而不是简单开发约定，降低开发过程中的人为执行失误，还能通过后台直接导入以往开发过的模块代码定义，提升开发效率。
  2. 低代码能力：有了标准化的事件来驱动业务，就能基于这套标准融入一定的低代码能力，框架不仅内置了用户模块，登录授权，权限管理等常用功能，还能通过配置方式，一键实现基础的参数校验、增删查改。
  3. AI 辅助开发：结合最新的 AI 技术，目前已经实现了自动化测试，未来还将实现 AI 辅助创建 SQL，通过 MCP 技术把业务上下文集成到 Vscode 的 AI 辅助编码工具中提高 AI 编码的准确性，降低编码工作量，提升开发效率。

二、DDD 过时了？4 招重构业务与技术边界​

领域驱动设计（DDD）虽好，但就目前市面上的框架设计思路来看，多数 DDD 开发框架把业务逻辑和技术实现混在一起，如果项目技术负责人统筹能力强问题还不大，否则开发人员一旦对业务逻辑理解产生分歧，容易增加协商成本或陷入"过度设计"陷阱。

EventMatrix 的做法是采用一部分 DDD 的思想，把业务定义和具体的接口实现进行分离，业务的领域事件定义通过管理后台，定义在数据库中，强制剥离技术设计和业务设计的场景，让人员职责更清晰，而具体调用的接口实现则通过 Worker 注册，然后 Gateway 路由来调用执行，使得框架上层设计具有 DDD 部分思想，底层接口技术实现则采用开发人员更熟悉的 MVC 模式。

EventMatrix 的创新在于：

  1. 业务设计和具体技术实现剥离：业务设计基于管理后台，通过项目、上下文、实体、事件等定义业务模型，而技术实现则在对应注册的 Worker 进行映射或编码实现，能灵活拆分组合微服务，然后采用传统 MVC 模式进行极小模块开发，让需求分析人员专注需求分析，开发人员专注于业务逻辑的实现。
  2. 事件驱动业务逻辑：用事件对 DDD 实体逻辑进行解耦映射，简化 DDD 各种概念，交给接口制定人来规定接口实现的业务范围和暴露范围，使其使用起来更像一个 API 框架而非一堆 DDD 概念代码搭建的代码集，大大降低学习成本，提升开发效率。
  3. 轻量化六边形架构：通过统一适配器模式解耦业务核心与通信协议，使同一套业务逻辑可同时支持 HTTP/WebSocket/MQTT 等多协议接入，保障业务核心不受技术选型束缚。
  4. 动态业务规则：内置了规则引擎，以供实现类似于聚合接口一样的效果，对于一些需要变更可在管理后台修改业务规则进行业务流程重新调整切换，而不需要开发人员重新发布和编写代码，，也能通过规则引擎拆解复杂业务场景。

三、AI 编码靠不住？4 招让 AI 编码更精准​

尽管大模型对长上下文的处理能力正在不断提高，但上下文长度与生成速度相信始终都会是反比关系，上下文越长生成速度就越慢，就当前 AI 的技术架构来看，AI 编程更适合小上下文，单独文件的代码片段生成，通过精确控制好输入的上下文信息能够避免产生 AI 幻觉代码，就目前的开发框架来看很多并没有为此做好设计，让 AI 实现生产级别的编码往往需要让其了解整个项目的上下文，这在大型项目中是不现实的，EventMatrix 则通过架构创新，可以轻松做到业务解耦，让 AI 在针对需要高度自定义业务逻辑的事件时，能精确获取到相关上下文信息，让 AI 辅助开发高效精确，EventMatrix 通过架构约束让 AI 辅助开发融入开发流程：

  1. 自动化测试验证：结合事件定义，内置了 AI 生成测试参数的测试模块，可以通过 AI 生成测试参数来验证接口，让测试工作高效且自动化，提高代码可靠性。
  2. 通过接口创建领域事件：通过项目、版本、上下文、实体、实体事件、实体属性等接口，规范化接口的定义，让 AI 能精确创建领域事件，生成内置基础 crud 方法。
  3. 为代码编辑器提 MCP 服务：对于需要高度自定义业务逻辑的事件，可以直接在管理后台配置规则，然后通过编辑器的 AI 插件调用 MCP 服务生成代码，实现自定义业务底层编码的 AI 辅助开发。
  4. 接口级权限控制：针对未来 AI 辅助开发场景，通过接口级细粒度权限管控，开发人员可精准定义数据访问边界，规避 AI 生成代码可能引发的越权风险；同时，权限校验逻辑与业务代码解耦设计，降低框架层面对业务逻辑的侵入性。

四、拒绝臃肿！高性能、低运维成本​

经历过 JAVA 微服务架构的同学应该都知道，框架的复杂度往往会超过业务需求本身，一个典型微服务系统需要维护服务发现、配置中心等 N+组件，而 EventMatrix，希望通过架构精简，实现极简设计，降低开发门槛、提升后端开发效率和降低运维成本：

  1. 架构角色简单：目前架构中只有三类角色，Gateway、Worker 和 Device（目前未开发），Gateway 负责事件路由、用户管理、配置管理、权限控制等架构层面的职责；Worker 负责业务逻辑处理职责；Device 负责硬件管理和负载均衡等运维职责，加上 Go 编译后二进制独立文件发布的形式，运维会变得更简单。
  2. 自带常用开发模块和管理后台：EventMatrix 提供一套专门用来满足基础需求的日志、监控、配置中心等基础工具模块，开箱即用，管理后台还具备低代码开发能力，让需求分析人员专注于业务逻辑的编排，而不需要关注底层技术实现。
  3. 内置高性能组件：任何架构在演化的过程中都难免因为业务越来越复杂而变得越来越臃肿，臃肿之后就容易发生性能问题，EventMatrix 尽可能采用目前经过测试对比以后最高性能的组件，领域对象采用高速本地缓存保证规则解析速度，并在某些场景使用零拷贝技术提升性能，同时放弃 Go 自带的 RPC，采用通讯效率更高更底层的 Gnet +自定义协议，尽量不让性能在框架层面照成过度损耗。

五、如何有效砍成本？从各种环节开始​

作为一名热衷于开发小工具并自建服务器运维的开发者，对运行成本尤为敏感，这也成为我放弃 Java 技术栈的动因之一，同样因为经常独立编写项目的需要，我也一直在思考如何有效降低开发成本，经过不断的打磨迭代，EventMatrix 主要通过以下方式降低投入成本：

  1. 降低开发成本：开发后台+自动生成文档+初级低代码能力，降低开发成本，提升开发效率。
  2. 降低测试成本：测试一直是开发人员的痛点，现在可以通过 AI 自动化测试，降低测试成本，保证代码质量。
  3. 降低运行成本：之所以选择 Go 语言作为基座，除了看中 Go 的高性能，还有就是运行的内存消耗相比 Java 要低很多,相信做过 Java 开发的同学都知道，Java 程序的内存占用往往是其他语言的几倍，加上 Spring 需要周边一系列的配套组件，只要多跑几个项目以后，服务器的开销就会变得很"可观"，而同样的内存占用 EventMatrix 则可以轻松的运行 10 倍以上的项目。
  4. 降低运维成本：通过内置的日志、监控、配置中心等工具，可以大大降低早期项目的运维成本，未来还将开发 Device 角色，让设备管理和负载均衡更加简单，确保项目规模上去以后也能摆脱 k8s 的依赖，让运维工作依然相对轻松。

EventMatrix 诞生于对传统开发范式的反思与 AI 编码浪潮的洞察。通过事件驱动架构实现业务与技术解耦，采用标准化事件定义+低代码配置+AI 辅助开发替代重复劳动，使开发者聚焦业务价值。借鉴 DDD 思想但规避过度设计，以精简六边形架构降低复杂度，结合 AI 自动化测试与智能编码，打造高效稳定的后端框架。从 CRUD 解放到 AI 融合，EventMatrix 不仅是开发效能的革新，更是面向智能化编程的前沿探索，推动技术回归服务业务的本质，希望为应对持续迭代的业务场景提供优雅的后端解决方案。