Dever 示例

examples/ 只保留两个入口：cms/ 是当前维护的应用示例，old/ 是旧语言合同和回归材料的归档。旧目录不符合当前 component/domain/role 应用布局，不应直接执行 dever check/run/build。

CMS 同时维护 Dever 源码和 Markdown 源码。两套实现使用同一目录与业务合同：

module/
  platform/tenant/          平台租户
  user/account/             凭据、登录、bootstrap CMD
  user/membership/          租户成员
  user/session/             登录会话
  user/authorization/       核心角色授权的业务入口
  content/category/         分类
  content/revision/         文章编辑与修订快照
  media/asset/              上传、Storage Port/Adapter
  publishing/schedule/      定时发布与 Job
  audit/operation/          操作审计
  system/health/            健康 CMD
  news/article/
    app/editing.dever
    app/publication.dever
    api/admin/manage.dever
    api/front/browse.dever
    domain.dever
    model.dever
    model/publication.dever
test/
  content/category/lifecycle.dever
  news/article/publish.dever
  user/account/bootstrap.dever
  user/account/validation.dever
  user/session/lifecycle.dever

Markdown 项目使用相同的目录和 API/CMD 声明，仅把源码扩展名换成 .dever.md 并补齐文档合同。

编译器从 API/CMD/Job 声明生成入口。平台租户、账号、成员与会话是 global type，保存在共享平台库；文章、分类、修订、媒体、排期和审计属于当前租户物理库。认证 verify 只读取 global Model 并建立只读用户与租户身份；接口权限由核心根据当前站点和角色自动校验，后续 API 才进入可信 tenant scope。一个职责文件可包含一组内聚方法，没有按函数拆文件。

文章通过 /news/article/admin/manage/create 创建，list/detail 查询，remove 删除草稿，publish 发布。编辑调用 /content/revision/admin/manage/create，传入 selected_article_id、expected_version、标题正文和可空分类/媒体 ID；版本冲突返回 409，文章更新和修订快照在同一事务内完成。文章不声明绕过这些规则的自动 REST 写接口。列表 SQL 直接返回同领域 app.ArticleView，不暴露私有 Model。

/publishing/schedule/admin/manage/schedule 接收文章 ID 和 publish_at；创建时验证作者与草稿状态，按真实到期时间入队。每个排期有独立任务键，同刻文章不会合并。任务执行仍由核心复验身份和权限；发布、审计和排期状态一并提交或回滚，完成任务重放不会重复写入。手动重复发布返回 409。

在仓库根目录执行：

dever check examples/cms/dever
dever check examples/cms/md
dever test examples/cms/dever
dever test examples/cms/md
dever fmt examples/cms/dever --check
dever fmt examples/cms/md --check
dever run examples/cms/dever -- user.account.bootstrap '{"tenant_key":"tenant-one","tenant_name":"Tenant One","email":"owner@example.com","display_name":"Owner","password":"change-me-now"}'
dever tenant migrate examples/cms/dever 1
dever tenant owner examples/cms/dever 1 admin 1
dever tenant owner examples/cms/dever 1 front 1

run/build 只读取各项目的 config/setting.json，运行数据写入各自 data/。先用 bootstrap CMD 建立平台租户、业务 Owner membership 与 Argon2 密码，再用返回的真实 tenant_id 执行 tenant migrate，并用返回的 tenant_id/user_id 分别 provision admin/front 核心 RBAC Owner；示例中的 1 只是首次空库的常见结果，不能在生产脚本里硬编码。两个站点各自通过同站点的 user/authorization/<site>/manage 接口管理普通角色。不带 CMD 参数时启动 admin/front HTTP API。test 不读取部署配置；每个涉及 Model 的测试使用独立临时 SQLite，并在结束后清理。

CMS 的五个应用测试验证分类、发布规则、账号引导/规范化和会话生命周期的正常业务输出，位于各项目根 test/；拒绝、过期等负向行为，以及带真实登录的 HTTP、并发编辑、上传、Job 重试/回滚验收见业务验收说明。普通测试不伪造认证上下文。编译器和 CLI 的 Rust 回归测试仍统一位于仓库根 test/，两者都不混入业务 module/。部署前必须替换示例 JWT secret，并把两个站点的 origin 和 Host 改成真实 HTTPS 入口；origin 描述反向代理外部地址，不是 Dever 内部监听地址。

旧示例仍可供编译器维护者查阅历史语义，但不能作为新 Dever 应用的目录、可见性或调用方式范本。

4.7 KiB Raw Blame History

Dever 示例

4.7 KiB

Raw Blame History