27 lines
1.3 KiB
Markdown
27 lines
1.3 KiB
Markdown
# 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`）。
|