Medusa 概念定义速查:编写教程与集成指南时的标准化术语规范
【免费下载链接】medusaThe world's most flexible commerce platform for agents and developers项目地址: https://gitcode.com/GitHub_Trending/me/medusa
导读
本文基于 Medusa 仓库中writing-tutorials技能体系的概念定义参考文件(concept-definitions.md),系统整理 Medusa 开发者在教程与集成指南中必须使用的标准化概念定义:从 Module、Data Model、Workflow 等基础概念,到 Notification、Payment、Auth 等 Module Provider 的专有定义。读完本文,你将掌握一套可直接复制、语义精确的概念定义模板与使用规则,并能对照仓库源码(如抽象基类、官方内置 Provider 实现)理解每个定义背后的技术约束。
一、这份参考文件在教程写作流程中的定位
在 Medusa 仓库中,教程写作由.claude/skills/writing-tutorials/SKILL.md定义的writing-tutorials技能驱动,采用"先构建功能、后撰写文档"的两阶段流程:
- Phase 1 — Build:需求收集 → 规划 → 在示例项目中实现功能 → 编写测试 → 与用户确认;
- Phase 2 — Write:绘制步骤图 → 分步撰写 MD 文件 → 合并为最终 MDX → 更新侧边栏 → 清理临时文件。
当进入 Phase 2(写作阶段)时,技能要求同时加载三个参考文件:reference/writing-phase.md、reference/tutorial-conventions.md与reference/concept-definitions.md。其中concept-definitions.md 专门负责"概念首次出现时的定义",其核心规则是:
当某个概念在教程步骤中第一次被引入时,必须在实现细节之前给出 1~2 句定义;定义文本应原样使用(或为贴合上下文做最小化改编),并始终在定义后紧跟一个
<Note>链接指向更详细的文档。
这意味着本文整理的所有定义都是"可直接复制进 MDX 教程"的标准用语,而非自由发挥的散文。配套的教程产出位置与侧边栏约束可参考 SKILL.md:教程存放于www/apps/resources/app/how-to-tutorials/tutorials/{name}/page.mdx,集成指南存放于www/apps/resources/app/integrations/guides/{name}/page.mdx,并需同步更新对应的how-to-tutorials.mjs/integrations.mjs侧边栏文件。
二、基础开发概念定义
这一组定义覆盖 Medusa 后端扩展的四大基石:模块、数据模型、服务与迁移。
1. Module(模块)
模块是 Medusa 一切自定义功能的载体,参考文件给出的标准定义如下:
In Medusa, you can build custom features in a module. A module is a reusable package with functionalities related to a single feature or domain. Medusa integrates the module into your application without affecting your setup.
In the module, you define the data models necessary for a feature and the logic to manage these data models. Later, you can build commerce flows around your module.
要点拆解:
- 可复用包:模块是围绕单一功能或领域打包的单元;
- 无侵入集成:Medusa 将模块集成进应用且不影响现有配置;
- 模块职责:在模块内定义功能所需的数据模型(Data Models)以及管理这些数据模型的服务逻辑,之后可基于模块构建商业流程(commerce flows)。
仓库中大量官方能力正是以模块形态存在的,例如packages/modules/下的notification、payment、auth、fulfillment、analytics、product、order、cart等目录,每个目录都是一个独立的模块包(拥有自己的package.json、tsconfig.json与mikro-orm.config.dev.ts)。写教程时该定义后应附带<Note>链接至 Modules 文档。
2. Data Model(数据模型)
A data model represents a table in the database. You create data models using Medusa's Data Model Language (DML), which simplifies defining a table's columns, relations, and indexes with straightforward methods and configurations.
关键信息:
- 数据模型 = 数据库中的一张表;
- 使用DML(Data Model Language)创建,DML 用直观的方法与配置简化列、关系、索引的定义,避免直接手写底层 ORM 映射。
DML 的底层实体定义在packages/core/utils与packages/core/modules-sdk中实现,模块内所有数据模型都会通过 MikroORM 映射为真实的数据库表。
3. Service(服务)
A service is a TypeScript or JavaScript class that the module exports. In the service's methods, you can connect to the database to manage your data models, or connect to a third-party service, which is useful when integrating with external systems.
要点:
- 服务是模块导出的 TypeScript / JavaScript 类;
- 在服务方法中可以连接数据库管理数据模型,也可以连接第三方服务——后者正是与外部系统集成的常用路径。
服务通常注册在模块的容器(container)中,其构造函数第一个参数注入模块依赖(如logger),第二个参数接收模块配置项options。这一点在抽象基类的 JSDoc 中有明确说明(见下文"Notification Module Provider"一节的源码佐证)。
4. Migration(迁移)
Since data models represent tables in the database, you define how to create them in the database using migrations. A migration is a TypeScript or JavaScript file that defines database changes made by a module.
- 数据模型定义了"表长什么样",而迁移定义了"如何在数据库中创建/变更这些表";
- 迁移是一个 TypeScript / JavaScript 文件,描述模块对数据库的变更。
三、模块间协作概念
5. Module Links(模块链接)
Module Links 是 Medusa模块隔离(Module Isolation)机制下的产物,标准定义为:
Medusa integrates modules into your application without side effects by isolating them from one another. This means you can't directly create relationships between data models in your module and data models in other modules.
Instead, Medusa provides a mechanism to define links between data models and to retrieve and manage linked records while maintaining module isolation. Links are useful for defining associations between data models in different modules or for extending a model in another module to associate custom properties with it.
要点:
- 模块之间相互隔离,不能直接跨模块建立数据模型关系;
- Medusa 提供Links机制:在保持模块隔离的前提下定义数据模型之间的关联,并可检索、管理被链接的记录;
- 适用场景:跨模块数据模型关联、为其他模块的模型扩展自定义属性。
仓库中packages/modules/link-modules即是这一机制的核心实现(包含 56 个源码文件及integration-tests),而各模块的links定义则分散在模块源码与集成测试中,例如integration-tests/modules/src/links目录。
6. Workflow(工作流)
To build custom commerce features in Medusa, you create a workflow. A workflow is a series of queries and actions, called steps, that complete a task. You can track the workflow's execution progress, define rollback logic, and configure other advanced features.
要点:
- 工作流 = 一系列**步骤(steps,即查询与动作)**串成的任务执行序列;
- 支持执行进度追踪、**回滚逻辑(rollback)**定义,以及多种高级配置。
工作流的运行时实现位于 packages/core/workflows-sdk/src,而 Medusa 内置的 847 个业务工作流源码集中在 packages/core/core-flows/src,可作为撰写工作流教程时的真实参考。
7. Workflow Hook(工作流钩子)
A hook is a specific point in a workflow where you can inject custom functionality.
- 钩子是工作流中一个特定注入点,开发者可在此插入自定义功能,实现不改动原工作流即可扩展行为。
四、接口层概念
8. API Route(API 路由)
An API route is created in a
route.tsfile under a sub-directory of thesrc/apidirectory. The path of the API route is the file's path relative tosrc/api.
- API 路由在
src/api目录的子目录下以route.ts文件创建; - 路由的路径 = 该文件相对
src/api的路径,即"文件即路由"。
9. Subscriber(订阅者)
A subscriber is an asynchronous function that runs in the background when specific events are emitted.
- 订阅者是一个异步函数,当特定事件被触发时在后台运行。
在仓库中,内置订阅者的示例位于packages/medusa/src/subscribers,集成测试项目的订阅者示例位于integration-tests/modules/src/subscribers。
10. Scheduled Job(定时任务)
A scheduled job is a function that runs at a specified interval in the background of your Medusa application.
- 定时任务是一个按指定时间间隔在 Medusa 应用后台运行的函数。
五、Admin 定制概念
11. Admin Dashboard Customization(Admin 仪表盘定制,引言段)
首次引入任何 Admin 定制内容时使用:
The Medusa Admin dashboard is customizable, allowing you to insert widgets into existing pages, or create new pages.
- Admin 仪表盘可定制:既可向既有页面插入Widget(组件),也可创建全新页面。
12. Admin UI Route(UI 路由 / 页面)
在创建新 Admin 页面时使用:
A UI route is a React component that specifies the content to be shown in a new page in the Medusa Admin dashboard.
- UI 路由是一个React 组件,决定 Admin 仪表盘新页面中展示的内容。
仓库中的 Admin 仪表盘本体位于 packages/admin/dashboard/src(包含 1000+ 个 TSX 组件),Admin 定制基础设施则分布在 packages/admin/admin-sdk、packages/admin/admin-vite-plugin 等包中。
六、第三方集成场景:Module Provider 定义
这是参考文件中结构最完整的一组定义,覆盖"为第三方服务编写集成"时的三类情形:内置模块 Provider、独立自定义模块。参考文件强调一个强制顺序:
对于集成指南:始终先使用 Generic Module Provider Intro(通用模块 Provider 引言),再在其下方追加模块专属定义(Notification、Payment 等)。
13. Generic Module Provider Intro(通用模块 Provider 引言)
在创建模块以集成第三方服务的步骤顶部使用:
To integrate third-party services into Medusa, you create a custom module. A module is a reusable package with functionalities related to a single feature or domain. Medusa integrates the module into your application without implications or side effects on your setup.
14. Notification Module Provider
在通用引言之后、且 Provider 实现 Notification 模块时使用:
Medusa's Notification Module delegates sending notifications to other modules, called module providers. In this step, you'll create a [Service Name] Module Provider that implements sending notifications through the [channel, e.g., email] channel.
A Notification Module Provider's service must extend the
AbstractNotificationProviderService. It has asendmethod that you'll implement to send notifications. The service must also have anidentifierstatic property, which is a unique identifier that the Medusa application uses to register the provider in the database.
该定义的三项硬性约束均有源码佐证:
- 抽象基类:
AbstractNotificationProviderService定义于 packages/core/utils/src/notification/abstract-notification-provider.ts#L48-L122。其 JSDoc 明确说明构造函数第一个参数用于访问模块容器中的依赖(如logger),第二个参数接收模块配置项options,且"创建第三方客户端或建立连接应在构造函数中完成"; identifier静态属性:基类声明static identifier: string(第 60 行),用于唯一标识 Provider,Medusa 应用以此在数据库中注册;send方法:基类默认抛出"send is not implemented"错误(第 114-122 行),强制子类实现;此外基类还提供了可选的static validateOptions(options)钩子用于校验medusa-config.ts中的 Provider 配置。
仓库官方实现可参考 packages/modules/notification/src/providers/medusa-cloud-email.ts#L5-L58:MedusaCloudEmailNotificationProvider继承抽象基类,声明static identifier = "notification-medusa-cloud-email",在send中通过fetch将通知载荷(to、from、template、data、attachments等)POST 至第三方端点。测试桩示例见 packages/modules/notification/integration-tests/fixtures/providers/default-provider.ts。
15. Payment Module Provider
Medusa's Payment Module provides an interface to process payments in your Medusa application. It delegates the actual payment processing to the underlying providers.
A Payment Module Provider's service must extend the
AbstractPaymentProviderclass. It must also have a staticidentifierproperty that uniquely identifies the provider.
Payment Provider 同样必须继承AbstractPaymentProvider并声明静态identifier。仓库内置的 packages/modules/payment/src/providers/system.ts#L37-L117 是极佳的教学样本:SystemPaymentProvider以static identifier = "system"注册,并实现了getStatus、initiatePayment、authorizePayment、capturePayment、refundPayment、cancelPayment、getWebhookActionAndData等一整套支付生命周期方法,完整呈现了支付 Provider 需要覆盖的接口面。
16. Fulfillment Module Provider
Medusa's Fulfillment Module delegates processing fulfillments and shipments to other modules, called module providers. In this step, you'll create a [Service Name] Module Provider that implements all functionalities required for fulfillment.
A Fulfillment Module Provider's service must extend the
AbstractFulfillmentProviderServiceclass.
履约 Provider 必须继承AbstractFulfillmentProviderService。该抽象类可从@medusajs/framework/utils导入,其接口面(创建履约、发货、取消等)可由 packages/modules/fulfillment/integration-tests/fixtures/providers/default-provider.ts 中的测试桩直观看到。
17. Analytics Module Provider
Medusa's Analytics Module provides an interface to track events in your Medusa application. It delegates the actual tracking to the configured Analytics Module Provider.
An Analytics Module Provider's service must extend the
AbstractAnalyticsProviderServiceclass. It must also have anidentifierstatic property with the unique identifier of the provider.
分析 Provider 继承AbstractAnalyticsProviderService并声明静态identifier。测试桩示例 packages/modules/analytics/integration-tests/fixtures/providers/default-provider.ts 中AnalyticsProviderServiceFixtures即以static identifier = "fixtures-analytics-provider"演示了最小实现形态。
18. Auth Module Provider
Medusa's Auth Module provides the interface to authenticate users. It delegates the actual authentication logic to the underlying Auth Module Provider.
An Auth Module Provider's service must extend the
AbstractAuthModuleProviderclass. It must also have aDISPLAY_NAMEstatic property for display in the UI, and anidentifierstatic property with the unique identifier of the provider.
Auth Provider 与其余 Provider 的关键区别在于多了一个DISPLAY_NAME静态属性(用于界面展示)。仓库官方实现 packages/modules/auth/src/providers/medusa-cloud-auth.ts#L28-L30 精准对应定义:
export class MedusaCloudAuthService extends AbstractAuthModuleProvider { static identifier = "cloud" static DISPLAY_NAME = "Medusa Cloud Authentication" }此外仓库还内置了 emailpass、github、google、oidc 等认证 Provider(见packages/modules/providers/auth-*各目录),可进一步对比不同 Provider 的validate/authenticate方法实现差异。
19. 自定义模块(非 Provider 场景)
当集成本身是独立自定义模块(而非内置模块的 Provider),例如接入 CMS、搜索引擎或其他第三方服务时:
To integrate third-party services into Medusa, you create a custom module. A module is a reusable package with functionalities related to a single feature or domain. Medusa integrates the module into your application without implications or side effects on your setup.
In this step, you'll create a custom module that provides the necessary functionalities to integrate [Service Name] with Medusa.
该定义与 Generic Module Provider Intro 前半部分一致,但后半句明确了落地形态:创建提供集成功能的自定义模块。
七、使用规范(Usage Guidelines)
参考文件最后给出五条硬性使用规则,直接决定定义能否被正确插入:
- 仅在概念首次出现时给出定义;
- 后续步骤复用同一概念时不再重复定义(例如第二个 workflow 不重复解释 workflow);
- 允许最小化改编以贴合上下文——例如将定义中的实体名替换为教程实际使用的实体名;
- 定义之后必须紧跟
<Note>,链接到相关文档页; - 集成指南必须遵循"先通用、后专有":先使用 Generic Module Provider Intro,再在其下方追加模块专属定义(Notification、Payment、Fulfillment、Analytics、Auth 等)。
另外还有一条针对 Module 的排他性提醒:若模块本身是 Module Provider,应使用该特定 Provider 的定义,切勿同时添加 Module 与 Provider 两套定义。
八、概念与源码对照总览
| 概念 | 核心约束 | 仓库佐证路径 |
|---|---|---|
| Module | 可复用、按领域打包、无侵入集成 | packages/modules/下各模块目录 |
| Data Model | 对应数据库表,用 DML 定义 | packages/core/utils、packages/core/modules-sdk |
| Service | 模块导出的 TS/JS 类,管理数据模型或对接第三方 | 各模块src/services目录 |
| Migration | TS/JS 文件,定义数据库变更 | 各模块src/migrations目录 |
| Module Links | 隔离前提下跨模块建关联 | packages/modules/link-modules/src |
| Workflow / Hook | 步骤序列 + 回滚;钩子注入自定义逻辑 | packages/core/workflows-sdk/src、packages/core/core-flows/src |
| API Route | src/api下route.ts,路径即文件路径 | packages/medusa/src/api |
| Subscriber | 事件触发的后台异步函数 | packages/medusa/src/subscribers |
| Scheduled Job | 按间隔运行的后台函数 | packages/medusa/src/jobs、packages/medusa/src/commands |
| Admin UI Route | React 组件,定义新页面 | packages/admin/dashboard/src |
| Notification Provider | 继承AbstractNotificationProviderService+identifier+send | abstract-notification-provider.ts、medusa-cloud-email.ts |
| Payment Provider | 继承AbstractPaymentProvider+identifier | system.ts |
| Fulfillment Provider | 继承AbstractFulfillmentProviderService | default-provider.ts |
| Analytics Provider | 继承AbstractAnalyticsProviderService+identifier | default-provider.ts |
| Auth Provider | 继承AbstractAuthModuleProvider+identifier+DISPLAY_NAME | medusa-cloud-auth.ts |
结语
concept-definitions.md的价值在于把"如何介绍一个概念"从个人写作习惯上升为团队级规范:定义文本统一、首次出现时机统一、文档链接统一,从而保证教程体系在成百上千个步骤中的一致性与可检索性。对读者而言,这套定义本身就是 Medusa 核心概念的最精炼提炼——每一个定义都能在仓库源码中找到对应的抽象基类或官方实现作为验证锚点。撰写 Medusa 教程或集成指南时,直接套用本文整理的定义模板,即可保证术语准确、结构合规、示例可运行。
【免费下载链接】medusaThe world's most flexible commerce platform for agents and developers项目地址: https://gitcode.com/GitHub_Trending/me/medusa
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考