# bff-orchestration

面向客户端的编排层：把多个 domain 的用例拼成"一个屏幕一个接口"的形状。

## 现在为什么是空的

首页聚合当前落在 `domains/workbench` 里（见 `WorkbenchAppService`），因为它只跨了
`identity-store` + 两个外部系统，用 domain 自己的 application 层就够了。

**在出现第二个"必须跨多个 domain 才能拼出来、且明显只服务于某一个客户端屏幕"的接口之前，
这个模块保持为空。** 提前把编排逻辑搬进来只会多一层转发。

## 什么时候开始往里写

同时满足这几条时，把编排从 domain 里搬进来：

- 一个接口需要 3 个以上 domain 的数据，且这些 domain 之间没有业务上的从属关系；
- 响应结构明显是为某个客户端页面定制的（换个端就得换一套）；
- 编排逻辑放在任何一个 domain 里都显得越界。

## 写进来时的约束

- 只能依赖各 domain 的 `-contract` 模块和 `platform-*`，**不能依赖任何 domain 的实现模块**；
- 自己不建表、不写 Flyway 迁移——BFF 没有自己的数据；
- 并行聚合照 `workbench` 的做法：专用有界线程池 + 上下文传播 + 接口级总超时预算
  （见 `../../conti-docs/backend/11-cross-domain-collaboration.md`）。