# OOPforge：为AI编码助手注入领域驱动设计纪律的轻量级方法论包

> OOPforge是一个面向Claude Code、Codex CLI、Cursor等AI编码工具的DDD/OOP方法论包，通过明确的六阶段工作流、严格的代码规范和可运行的Java/Python示例，帮助AI生成结构清晰、可维护的领域驱动代码，避免典型的God Service反模式。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-06-01T00:14:53.000Z
- 最近活动: 2026-06-01T00:19:27.896Z
- 热度: 145.9
- 关键词: DDD, OOP, AI编码助手, 领域驱动设计, Claude Code, Codex CLI, Cursor, Clean Architecture, Java, Python
- 页面链接: https://www.zingnex.cn/forum/thread/oopforge-ai
- Canonical: https://www.zingnex.cn/forum/thread/oopforge-ai
- Markdown 来源: ingested_event

---

## 原作者与来源

- **原作者/维护者**: LooSung (GitHub: @LooSung)
- **来源平台**: GitHub
- **原始标题**: oopforge: Portable OOP/DDD methodology pack for AI coding agents
- **原始链接**: https://github.com/LooSung/oopforge
- **发布时间**: 2026年6月1日

---

## 背景：AI编码助手的架构困境

随着Claude Code、Codex CLI、Cursor等AI编码助手的普及，开发者们发现一个新问题：AI生成的代码虽然功能正确，但架构质量往往堪忧。最典型的表现就是**God Service**反模式——一个服务类包揽了验证、定价、持久化、事件发布等所有职责，业务规则散落各处，单元测试难以编写，维护成本随时间线性增长。

问题的根源在于，AI模型虽然理解语法，但缺乏**架构纪律**。它们倾向于复制训练数据中最常见的模式，而Spring的@Service注解配合过程式代码正是最常见的默认选择。开发者需要一种方法，让AI在生成代码前就理解并遵循领域驱动设计（DDD）的原则。

---

## OOPforge 是什么

OOPforge是一个**面向AI编码助手的OOP/DDD方法论包**，它不是通用的agent框架，而是专注于解决一个具体问题：如何让AI生成符合领域驱动设计、六边形架构和整洁代码规范的软件。

项目的核心理念可以用一句话概括：**Forge small. Compose forever.**（小处着手，持久组合）。它通过以下设计原则实现这一目标：

| 原则 | 含义 |
|------|------|
| **Small** | 一个skill只负责一个概念，控制在200行以内 |
| **Measurable** | 单文件≤300行，单方法≤20行，保持可审查的粒度 |
| **Workflow-first** | Discovery → Design → Skeleton → Implement → Test，每阶段设有人工检查点 |
| **Proof over philosophy** | 提供可运行的Java/Python示例，而非幻灯片式理论 |
| **Domain-first** | 领域层零框架依赖，确保业务逻辑的纯粹性 |

---

## 六阶段工作流详解

OOPforge定义了一套完整的六阶段工作流，每个阶段都有明确的输入输出和验收标准：

### 1. Discovery（领域发现）

在写任何代码之前，AI首先与开发者一起探索业务领域。以图书馆借阅系统为例，这一阶段会识别出核心概念：会员（Member）、图书（Book）、借阅记录（Loan）、领域事件（BookBorrowed）。关键是**先建模，后编码**，避免过早陷入技术细节。

### 2. Design（用例设计）

基于发现阶段产出的领域模型，设计具体的用例。例如借阅图书用例会定义：输入命令（BorrowBookCommand）、输出结果、前置条件（会员状态正常、图书可借）、后置条件（创建借阅记录、发布领域事件）。

### 3. Delivery Plan（交付计划）

将设计分解为可实现的步骤，明确各层（领域层、应用层、适配器层）的职责边界。这一步确保实现路径清晰，避免在编码过程中迷失方向。

### 4. Skeleton（骨架生成）

生成项目的目录结构和接口定义，但不实现具体逻辑。OOPforge支持Java Spring和Python FastAPI两种技术栈，开发者只需选择其一。骨架代码严格遵循六边形架构：

```
order/domain/Order.java              ← 聚合根（零框架import）
order/application/provided/PlaceOrder.java
order/application/required/OrderRepository.java
order/application/service/PlaceOrderService.java
order/adapter/web/OrderController.java
order/adapter/persistence/InMemoryOrderRepository.java
```

### 5. Implement（实现）

填充骨架中的业务逻辑。OOPforge通过一系列硬性规则约束代码质量：禁止public setter，使用静态工厂方法；集合边界处进行防御性拷贝；领域逻辑必须有单元测试覆盖。

### 6. Test（测试）

验证实现是否符合设计，运行完整的测试套件。OOPforge还提供domain-reviewer检查器，自动扫描代码中的规则违反。

---

## Before vs After：代码结构的质变

### 典型的Before代码（God Service模式）

```java
@Service
public class OrderService {
    public void createOrder(CreateOrderRequest req) {
        // 验证、定价、持久化、事件发布——全部挤在一个类里
        orderRepository.save(toEntity(req));
        eventPublisher.publish(...);
    }
}
```

问题显而易见：没有领域模型、业务规则散落、难以单元测试、AI会不断复制这种模式。

### OOPforge的After代码（领域优先模式）

```java
// 领域层：纯业务逻辑，零框架依赖
Order order = Order.place(orderId, customerId, lines);

// 应用层：协调用例
placeOrder.handle(command);

// 基础设施层：技术细节隔离
orderRepository.save(order);
order.popEvents(); // OrderPlaced
```

效果是立竿见影的：领域逻辑清晰可测、边界明确、AI可以重复生成符合相同布局的代码。

---

## 多Agent支持与实际使用

OOPforge通过symlink机制支持多种AI编码助手：

| Agent | 状态 | 安装目标 |
|-------|------|----------|
| **Claude Code** | 已支持 | ~/.claude/{skills,agents,commands}/oopforge |
| **Codex CLI** | 已支持 | ~/.codex/skills/oopforge |
| **Cursor Agent CLI** | 实验性 | cursor-agent --plugin-dir ~/.oopforge |
| **OpenCode** | 实验性 | INSTALL_OPENCODE=1 ./scripts/setup/install.sh |

安装后，开发者可以通过斜杠命令驱动整个工作流：

```
/oopforge:discovery order domain
/oopforge:design place-order use case
/oopforge:delivery-plan place-order
/oopforge:skeleton java-spring
/oopforge:implement place-order
/oopforge:test place-order
```

或者直接使用自然语言：

> Build an Order aggregate in Java, following OOPforge rules.

---

## 技术细节与硬性规则

OOPforge的成功不仅在于流程设计，更在于一系列**可量化的硬性规则**：

- **领域层框架import数：0** —— 确保业务逻辑纯粹
- **单文件行数：≤300行** —— 保持代码审查的可行性
- **单行方法行数：≤20行** —— 单一职责原则
- **单skill文件行数：≤200行** —— 一个概念对应一个上下文
- **禁止public setter** —— 使用静态工厂方法控制对象创建
- **边界防御性拷贝** —— 防止集合被外部修改
- **无测试不逻辑** —— 领域逻辑必须有单元测试覆盖

这些规则不是建议，而是**红线**。违反规则的代码无法通过OOPforge的审查流程。

---

## 项目结构与内容一览

OOPforge的仓库结构清晰反映了其设计理念：

```
skills/
├── workflow/        # Discovery → Design → Skeleton → Implement → Test
├── oop/             # Aggregate Root, Value Object, Domain Event等概念
└── lang/
    ├── java/        # Spring六边形布局、JPA仓库模式
    └── python/      # Pydantic值对象、整洁FastAPI布局

agents/              # ddd-architect子代理
commands/            # Claude Code斜杠命令
examples/            # 可运行的Java/Python示例
scripts/             # 安装、检查、CI脚本
```

项目提供了完整的图书馆借阅系统教程（支持中、英、日、韩四种语言），以及订单系统的最小可运行示例，开发者可以边学边练。

---

## 发展路线图

OOPforge目前处于Phase 1阶段，作为一个轻量级可移植的方法论包通过symlink分发。未来计划包括：

- **Phase 2**: 进入Claude Code、Codex、Cursor的官方插件市场
- **Phase 3**: 基于Claude Agent SDK构建独立CLI工具

---

## 总结与启示

OOPforge的价值不仅在于它提供了一套DDD/OOP的最佳实践，更在于它**将架构纪律编码为AI可执行的规则**。在AI编码助手日益普及的今天，开发者需要的不是让AI自由发挥，而是给它明确的约束和检查点。

正如项目文档中所说：**Model is replaceable. Workflow is permanent.** 模型会不断变化，Claude、GPT、开源模型以及未来的新技术会层出不穷，但良好的工作流程、清晰的契约和架构纪律将长期存在。

对于希望提升AI生成代码质量的开发者和团队，OOPforge提供了一个立即可用的解决方案。它不需要重构现有项目，只需在下次启动AI编码助手时，多一道遵循OOPforge规则的指令，就能看到代码质量的显著提升。

---

## 相关链接

- **GitHub仓库**: https://github.com/LooSung/oopforge
- **快速安装命令**: 使用bootstrap脚本一键安装
- **图书馆借阅教程**: https://github.com/LooSung/oopforge/tree/main/docs/guides/library-loan
- **许可证**: MIT