# tech-forge-devp

**Repository Path**: lh0811-open/tech-forge-devp

## Basic Information

- **Project Name**: tech-forge-devp
- **Description**: TechForge基础代码开源
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 4
- **Forks**: 0
- **Created**: 2025-05-25
- **Last Updated**: 2025-12-25

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 1. Tech Forge 开发平台定义

    Tech Forge：强调技术创造和创新的过程，就像铁匠在锻造炉中锻造金属一样，这个平台能够锻造出高质量的技术解决方案。

特点：

1. 源码级别可拓展的用户认证授权、鉴权组件。
2. 支持多租户。
3. 在RBAC的权限基础上，通过"换人不换岗"的设计理念，实现了以岗位为核心的权限模型。确保人员变动不影响权限体系。
4. 动态的数据权限配置。

服务启动类：[TechForgeBondApplication.java](forge-app-bond/src/main/java/com/lh0811/forge/TechForgeBondApplication.java)

### 前端代码获取
加入知识星球，在置顶文件中获取！手搓代码不易，谢谢大家支持！
(づ￣3￣)づ╭❤～ https://t.zsxq.com/hLe8M

# 2. 系统设计理念

想要说明系统的设计理念，需要先要说明以下的关键点

* 如何理解分布式系统？
* 如何理解微服务？
* 如何理解DDD设计思想？

## 2.1 理解分布式系统

分布式系统指的是计算机的软件和硬件分布在不同的计算机上，彼此之间仅仅通过网络通讯、消息传递来协调整个系统。 分布式系统的特点。

* 节点分布性: 分布式系统中的每个节点都有可能在不同的物理空间或网络空间中。
* 节点平等性: 分布式系统中的每个节点都不存在从属关系，都是平等提供计算服务的节点。
* 请求并发性: 分布式系统中的节点会并发性的处理全局资源和数据，这也是分布式系统最大的挑战。

这里不对分布式系统的特点和挑战做详细的展开，只是表达出分布式系统的特点，以便于大家对分布式系统的理解。

## 2.2 理解微服务

‌微服务是一种软件架构风格‌，它将一个大型软件应用程序拆分成多个小型、自治的服务单元。每个服务单元都专注于实现特定的业务功能，并且可以独立部署、扩展和维护。这些服务通过轻量级的通信机制（如‌HTTP
API）进行通信，通常使用不同的编程语言和技术栈实现，使得团队可以更加灵活地开发和维护各个服务。微服务的核心思想是将应用程序的不同功能模块化，以便更易于管理、扩展和升级。

同时，微服务在实际的实践中，也存在一些问题 借助论文《Towards Modern Development of Cloud Applications》中提出的微服务的五个问题。

* 损害性能: 序列化数据并通过网络发送的开销日益成为瓶颈。当开发人员过度分割他们的应用程序时，这些开销就会增加
* 损害了正确性: 推理每个微服务的每个部署版本之间的交互是极具挑战性的, 在对八个广泛使用的系统的 100
  多个灾难性故障的案例研究中，三分之二的故障是由系统的多个版本之间的相互作用引起的
* 很难管理 : 开发人员必须管理不同的二进制文件，每个二进制文件都按照自己的发布计划，而不是构建、测试和部署单个二进制文件,
  使用应用程序的本地实例运行端到端测试成为一项工程壮举
* 冻结API: 一旦微服务建立了 API，就很难在不破坏使用该 API 的其他服务的情况下进行更改。 造成旧版 API 依然存在，新的 API
  则在其上进行修补
* 减慢应用开发速度 : 当进行影响多个微服务的更改时，开发人员无法以原子方式实现和部署更改。 他们必须仔细计划如何通过自己的发布时间表在
  𝑛 微服务中引入更改。

其实，在真正的实践中，我最大的感受是微服务的划分至关重要。

一个合理的划分，可以让每个微服务各司其职，同时其服务边界明确，在开发和维护过程中可以体现出“高内聚，低耦合”的特点。

但是，这对系统设计能力提出了很高的要求。这也是DDD可以广为传播的原因。

## 2.3 理解DDD设计思想

DDD 领域驱动设计，被认为是目前对微服务划分问题的一个理论基础。

也是因为DDD只是提出了理论概念，而没有像MVC一样，提供一套可用的代码分包和编写规范，所以导致DDD在实践中的落地变得比较困难。在很多实践中名存实亡。

我理解，DDD他表达出的理念还是“面向对象”的设计思想。

首先，我们可以思考，最初我们学习“面向对象”时，是如何来做的？

比如：猫吃鱼。 这个描述中，我们把名称作为对象，动词作为方法。 这是一种最简单的“面向对象”的思考方式。

DDD要求我们，在一个复杂业务需求中尽可能的找出 找到其中的 domain也就是领域对象，描述domain的值对象，并对他们有个一明确的定义和认知。

这其中会有显性的对象也会存在隐性的概念,把隐性的概念显性化是需要对业务有足够的了解的。

当然，有很大的可能性，在系统开发之初，我们是没有办法发现隐式概念的。需要等到我们在真正开发一个业务时，发现各种不适或别扭的时候，我们就需要及时的反思，是不是我们忽略了某个隐式的概念。然后，重构他的设计。

我们不只是要找出领域对象，还要找到 业务领域内的 指令、事件，并对他们的相关性做出分析，最终完成一个由指令、事件驱动的业务模型。

这里我们不对DDD应该如何去落地，是否有一个可行的银弹方案做讨论。

在本项目中，我们借鉴DDD的一些指导思想，结合模块化开发的思路，对系统进行搭建。

## 2.4 一个微服务一定就是要独立部署的吗？

这个问题是一个闲谈，通过对分布式服务和微服务概念的理解，可以得到一个结论：

项目的微服务化与分布式系统是两个互不相关的概念。

换句话说，一个微服务中的每个模块既可以独立部署，也可以集成在一起部署。

具体应该如何部署，我想应该取决于某个微服务模块是否已经拖累了整体应用的运行性能，或者我们是否有足够多的机器允许我们来做多节点的部署。

在当前这个项目中，只是对微服务开发的一个脚手架，所以我会把所有的模块都集成到一个Springboot jar中来交付。

后续如果确实有需求需要把某些模块拿出来独立部署我会写个简单的教程来描述下如何操作。

# 3. 平台规划

## 3.1 规划图

![系统规划图1.png](static/img/%E7%B3%BB%E7%BB%9F%E8%A7%84%E5%88%92%E5%9B%BE1.png)

## 3.2 层级描述

先看整体架构（指向图片），这是一个典型的分层架构，从下到上层层支撑，越往上越贴近业务。我来划个重点：

1️⃣ 部署环境：底层用Docker，当然你也可以换成K8S或其他，灵活适配。

2️⃣ 基础设施：MySQL、Redis、MQ这些“基建狂魔”不用多说，系统跑起来的必需品。

3️⃣ 基础服务：集成了分布式任务调度（snail-job）、对象存储（Minio）等“瑞士军刀”，开箱即用。

4️⃣ 平台级能力：这里是TechForge的“核心竞争力”！比如用户中心、租户管理，未来还会扩展消息服务、工作流引擎——所有能力都通过API开放给上层。

核心亮点：元数据服务 vs 业务应用

重点来了！基础应用层的元数据服务，是TechForge实现复用的“灵魂”。

什么是元数据？——它是现实世界的抽象。比如“空间”这个概念，可以是教室、酒店房间，甚至是停车位。这些实体在业务中千变万化，但本质都是“空间”。

举个栗子

假设我们要开发自习室预约系统：

● 业务层：处理预约规则、时段冲突等具体逻辑。

● 元数据层：用“空间服务”统一管理教室的物理属性（位置、容量等）。

下次接到酒店管理系统需求时，直接复用“空间服务”管理房间，业务层只需扩展价格、房型等特有字段。

为什么这样做？

1️⃣ 减少重复造轮子：通用能力下沉到元数据层，业务层只关注差异化。

2️⃣ 快速响应需求：新业务只需“填空”，不用从头设计基础模型。

3️⃣ 贴近现实世界：当元数据足够丰富，它们就是数字世界的“镜像”，业务交互自然水到渠成。

# 4. 模块划分

* forge-dependency:
    * 模块名称：依赖管理模块
    * 职责：TechForge开发脚手架中对常用依赖Maven包的整合。以及一些自研发的开发框架。
* forge-plate-serv:
    * 模块名称：平台服务模块
    * 职责：包含平台提供的平台基础能力。比如：权限管理、代码生成...
* forge-mdata-serv:
    * 模块名称：元数据服务模块
    * 职责：包含平台中元数据管理的服务。比如：地点管理、设备管理。
* forge-app-serv:
    * 模块名称：业务应用模块
    * 职责：包含基于元数据开发的面向业务的应用。比如：酒店管理、校园管理。
* forge-app-bond:
    * 模块名称：交付包
    * 职责：负责将需要交付的模块统一打包成一个Springboot Jar。

每个模块都分为：xxx-api 和 xxx-server 两个子模块，api子模块负责将当前模块需要暴露给其他模块引用的Api和Bean。server子模块则实现当前模块的具体业务。

# 5. 模块的包划分

根目录:
com.lh0811.forge
模块目录:(已平台服务中的用户中心uacs模块为例)

* api子模块包： com.lh0811.forge.模块(如plate).子模块(如uacs).api
    * com.lh0811.forge.模块(如plate).子模块(如uacs).api.api -- 暴露给外部的API接口（实现在server中）。
    * com.lh0811.forge.模块(如plate).子模块(如uacs).api.constant -- 暴露给外部的常量
    * com.lh0811.forge.模块(如plate).子模块(如uacs).api.param -- 暴露给外部的Param参数
    * com.lh0811.forge.模块(如plate).子模块(如uacs).api.vo -- 暴露给外部的Vo参数
    * com.lh0811.forge.模块(如plate).子模块(如uacs).api.component -- 暴露给外部的组件

* server子模块包： com.lh0811.forge.模块(如plate).子模块(如uacs).server
    * com.lh0811.forge.模块(如plate).子模块(如uacs).server.adapter.controller -- 外部接入适配器 HTTP
    * com.lh0811.forge.模块(如plate).子模块(如uacs).server.adapter.event.customer -- 外部接入适配器 事件消费者
    * com.lh0811.forge.模块(如plate).子模块(如uacs).server.adapter.event.provider -- 外部接入适配器 事件提供者
    * com.lh0811.forge.模块(如plate).子模块(如uacs).server.api.impl -- api模块中，对外暴露接口的实现
    * com.lh0811.forge.模块(如plate).子模块(如uacs).server.component -- 组件实现
    * com.lh0811.forge.模块(如plate).子模块(如uacs).server.config -- 模块配置
    * com.lh0811.forge.模块(如plate).子模块(如uacs).server.repository -- 数据库逆向生成的ORM代码
    * com.lh0811.forge.模块(如plate).子模块(如uacs).server.service -- 模块业务实现