Files
core/examples

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 应用的目录、可见性或调用方式范本。