Back to Details

enterprise-ddd

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Enterprise DDD Architecture

企业级DDD架构

Use this skill for large systems where domain boundaries, ownership, and cross-team scaling matter more than local feature speed.

当领域边界、所有权和跨团队扩展性比本地功能开发速度更重要时，使用此架构方案。

Use This Skill When

适用场景

Multiple domains must be isolated (billing, auth, catalog, attendance, etc.).
You need explicit module contracts across frontend and backend.
Event-driven integration is preferred over direct cross-module coupling.
Monorepo governance and release boundaries are required.

必须隔离多个领域（如计费、认证、商品目录、考勤等）。
需要在前端和后端之间明确模块契约。
优先选择事件驱动集成而非直接跨模块耦合。
需要对单体仓库（monorepo）进行治理并明确发布边界。

Do Not Use When

不适用场景

Project is small or single-team with low domain complexity.
A simple layered architecture is sufficient.

项目规模小或仅由单一团队负责，领域复杂度低。
简单的分层架构已足够满足需求。

Architecture Contract

架构契约

Model domain boundaries first (bounded contexts).
Keep each domain module internally FSD-like and externally contract-based.
Forbid deep cross-module imports.
Communicate across modules/services with events or stable APIs.
Maintain separate deployable apps and services.
Keep shared packages infra-only (
```
types
```
,
```
ui
```
,
```
config
```
,
```
utils
```
).

首先建模领域边界（限界上下文）。
每个领域模块内部保持类FSD结构，外部基于契约交互。
禁止深度跨模块导入。
通过事件或稳定API在模块/服务之间进行通信。
维护独立的可部署应用和服务。
共享包仅包含基础设施相关内容（如
```
types
```
、
```
ui
```
、
```
config
```
、
```
utils
```
）。

Recommended Structure

推荐结构

text

apps/              deployable apps
modules/           bounded-context frontend modules
services/          bounded-context backend services
packages/          shared infrastructure packages
infrastructure/    deployment and platform resources

text

apps/              可部署应用
modules/           限界上下文前端模块
services/          限界上下文后端服务
packages/          共享基础设施包
infrastructure/    部署与平台资源

Implementation Workflow

实施流程

1) Domain Modeling

1) 领域建模

List domains and ownership.
Define each module public API (
```
index.ts
```
) first.
Define event contracts and versioning.

列出领域及所属团队。
先定义每个模块的公共API（
```
index.ts
```
）。
定义事件契约及版本控制规则。

2) Module Design (Frontend)

2) 模块设计（前端）

Apply FSD inside a domain module:
```
entities
```
,
```
features
```
,
```
widgets
```
,
```
shared
```
.
Export only public APIs from module root.
Keep domain state and API hooks inside module boundary.

在领域模块内部应用FSD：
```
entities
```
,
```
features
```
,
```
widgets
```
,
```
shared
```
.
仅从模块根目录导出公共API。
将领域状态和API钩子保持在模块边界内。

3) Service Design (Backend)

3) 服务设计（后端）

Keep domain, application, infrastructure, presentation separation.
Use repository interfaces in domain layer and implementations in infrastructure.
Emit domain events for cross-service actions.

保持领域层、应用层、基础设施层、表现层分离。
在领域层使用仓库接口，在基础设施层实现具体逻辑。
针对跨服务操作发布领域事件。

4) Integration Rules

4) 集成规则

Allowed: event bus, API client boundary, declared public exports.
Forbidden: direct imports into other module internals.
Enforce via lint/import rules in CI.

允许：事件总线、API客户端边界、已声明的公共导出。
禁止：直接导入其他模块的内部内容。
通过CI中的lint/导入规则强制执行。

5) Rollout

5) 部署推广

Start with 1-2 high-value domains.
Add generators/templates for new domain modules.
Track coupling metrics and refactor hot paths.

从1-2个高价值领域开始。
为新领域模块添加生成器/模板。
跟踪耦合指标并重构热点路径。

Decision Matrix

决策矩阵

Need independent scaling per domain: choose DDD.
Need strict module ownership across teams: choose DDD.
Need fastest delivery on small scope: avoid DDD for now.

需要按领域独立扩展：选择DDD。
需要跨团队的严格模块所有权：选择DDD。
小范围需求需要最快交付：暂时避免使用DDD。

Output Requirements for Agent

Agent输出要求

Propose target domain map.
Provide import/event boundary rules.
Provide migration plan from current structure to target structure.
Include risks, rollback plan, and testing strategy.

提出目标领域映射。
提供导入/事件边界规则。
提供从当前结构到目标结构的迁移计划。
包含风险、回滚计划和测试策略。

References

参考资料

Detailed structures, code templates, generators, and examples:
```
references/guide.md
```

详细结构、代码模板、生成器及示例：
```
references/guide.md
```