寄语：林深时见鹿，海蓝时见鲸，梦醒时见你。一切美好从你我相遇开始。遇见鹿鲸，开启美好项目之旅...

     续上篇文章《这才是低代码的未来？AI驱动下的功能模块设计新思路首曝》，今天，我即将分享自己在做《鹿鲸项目管理工具》技术选型的一些核心考量与架构主张。

     在如今“言必称微服务、云原生”的技术圈，很多开发者在启动新项目时容易陷入一种“架构焦虑”：明明团队只有几号人，业务量也没那么大，却硬着头皮上Spring Cloud，结果被多服务调用、分布式事务、链路追踪搞得焦头烂额。    

      今天，我想和大家分享一套自己长期沉淀下来的“反内卷”但又具有稳定性和前瞻性的前后端技术选型方案。它放弃了沉重的微服务枷锁，回归到单体架构的敏捷，同时采用多包模块拆分设计理念，能够友好支撑系统业务模块功能的横向扩展。

    这套“反内卷”技术选型方案就是：

    🎨 前端展现层：

• VUE3.0：核心渐进式框架，提供流畅的用户交互体验。
• VITE：极速构建工具，大幅提升开发与热更新速度。
• Element-Plus：成熟的企业级 UI 组件库，快速搭建后台界面。
• Pinia：替代传统的 Vuex，作为 Vue3 官方推荐的状态管理库

    ⚙️ 后端服务层

• JDK 21 + Spring Boot 3.x (单体)：敏捷的底层基石，兼顾高并发性能与开发效率。
• PostgreSQL + Redis：强大的数据存储与高性能缓存组合。
• MyBatis Flex：灵活的 ORM 框架，简化数据库操作。
• Sa-Token：轻量级权限认证，开箱即用，极简鉴权。
• SwaggerUI：标准化 API 文档生成，提升前后端联调效率。 

      特别说明：本文重在探讨 AI 低代码“单体+模块拆包”的架构哲学，所列技术选型仅为项目当前的成熟实践缩影。更多底层技术的具体落地与深度剖析（比如：绘制流程图采用drawio,接口测试使用ApacheJMeter_core等等)，将在后续推文中逐步展开，敬请关注。

🛠️ 为什么是这套“反内卷”技术选型方案

      正如我们在上一篇文章中所探讨的，AI低代码本质上是企业研发规范的数字化载体。从实际落地场景来看，这类管理平台的用户群体主要聚焦于企业内部的技术、产品及运维人员。他们借助该平台的核心目的，是高效生成并创造其他业务系统。这就决定了对于大多数中小企业而言，其并发访问量往往维持在几十到几百人的量级，并不存在海量用户的压力。因此，摒弃沉重的微服务架构，回归单体架构，无疑是当下最具性价比且最为明智的选择。

      抛开用户规模不谈，单从“降本增效”和“系统稳定”的角度来看，中小企业做内部平台放弃微服务、坚守单体架构是非常明智的。但我们说的单体，绝不是把所有代码揉成一团的“大泥球”，而是采用“逻辑上拆分，物理上聚合”的模块化思路。

      首先是开发快、成本低。真正的微服务需要处理分布式事务、链路追踪等复杂问题，对几十人的团队来说无异于“大炮打蚊子”，既拖慢进度又浪费服务器资源。而我们的模块化单体，只是在代码目录结构（包名）上将业务划分清楚。它保留了单体应用部署一步到位、没有跨网络通信开销的优势。这样大家就能把100%的精力放在写业务代码和打磨AI能力上，实现低成本下的快速上线。

      其次是更稳定、好维护。在微服务架构下，一个小模块出问题很容易引发“雪崩”，导致整个系统瘫痪；调用链路太复杂，排查Bug就像盲人摸象。但在模块化单体中，所有组件都在同一个运行环境里，模块之间的调用只是本地内存的方法调用，几乎没有延迟，也不用担心网络波动。加上代码集中管理，找Bug和调试都更直接高效。

      简单来说，我们用模块化的思路理清了业务边界，同时又享受了单体架构的红利。在资源有限的情况下，这种模式能用最少的运维成本，给企业提供一个最稳、最快、最好用的技术底座。

📦模块拆分：形散而神聚的演进策略

      放弃微服务不等于回到“面条代码”。为了让系统具备横向扩展的能力，我在单体内部实施了严格的多包模块拆分设计理念：

1.按业务边界垂直切换

      打破传统的按技术分层（Controller/Service/Dao），改为按业务领域划分包结构。根据上一篇文章功能模块设计，我们目前将包分为如下图所示。每个模块拥有自己的业务逻辑，实现高内聚。

后端核心包拆分

后端业务模块包拆分

前端核心包拆分

2.依赖倒置与接口隔离

      模块之间严禁直接跨层调用或数据库表Join。所有跨模块交互必须通过定义清晰的内部 API 接口（Interface）进行，底层实现完全封装。这不仅降低了耦合度，也为未来可能的服务拆分留下了标准契约。

3.共享内核

      抽取各模块通用的基础组件（如统一异常处理、全局日志、通用工具类、基础实体类）放入framework下独立模块中，避免重复造轮子，同时保证全系统基础规范的一致性。

4.渐进式演进路线

      这种拆分方式允许团队在项目初期像写单体一样高效开发，但当某个模块（如AI助手）成为性能瓶颈或需要独立扩容时，可以将其无缝剥离为独立的微服务，真正实现“架构是演进而来的”。

💡 写在最后

      架构是演进而来的，并非设计出来的。技术选型没有绝对的“最好”，只有“最合适”。面对AI时代的浪潮，我们既要保持对新技术的敏锐，又要坚守工程化的底线。这套前后端分离的单体模块化架构，正是《鹿鲸项目管理工具》拥抱变化、稳步前行的基石。

下期预告：接下来我将分享如何利用编码规范提升研发效率，题目为《AI重构低代码：从单体模块化到团队协作，一套“反焦虑”的代码规范长什么样？》，我们不见不散！！