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）。