后端: 1. 阶段 3 notification 服务边界落地,新增 `cmd/notification`、`services/notification`、`gateway/notification`、`shared/contracts/notification` 和 notification port,按 userauth 同款最小手搓 zrpc 样板收口 2. notification outbox consumer、relay 和 retry loop 迁入独立服务入口,处理 `notification.feishu.requested`,gateway 改为通过 zrpc client 调用 notification 3. 清退旧单体 notification DAO/model/service/provider/runner 和 `service/events/notification_feishu.go`,旧实现不再作为活跃编译路径 4. 修复 outbox 路由归属、dispatch 启动扫描、Kafka topic 探测/投递超时、sending 租约恢复、毒消息 MarkDead 错误回传和 RPC timeout 边界 5. 同步调整 active-scheduler 触发通知事件、核心 outbox handler、MySQL 迁移边界和 notification 配置 文档: 1. 更新微服务迁移计划,将阶段 3 notification 标记为已完成,并明确下一阶段从 active-scheduler 开始
30 lines
1.5 KiB
Go
30 lines
1.5 KiB
Go
package sv
|
||
|
||
import notificationfeishu "github.com/LoveLosita/smartflow/backend/services/notification/internal/feishu"
|
||
|
||
// FeishuWebhookProviderOptions 定义生产默认飞书 Webhook provider 的启动参数。
|
||
//
|
||
// 职责边界:
|
||
// 1. 只承载 provider 初始化需要的外部配置,不暴露 internal/feishu 的具体实现;
|
||
// 2. 不负责 notification 状态机参数,重试次数和扫描批量仍由 ServiceOptions 管理;
|
||
// 3. 后续若新增 OpenID 等 provider,应新增对应构造器,避免把多 provider 分支堆进 cmd 入口。
|
||
type FeishuWebhookProviderOptions struct {
|
||
FrontendBaseURL string
|
||
}
|
||
|
||
// NewNotificationServiceWithFeishuWebhook 创建生产默认的飞书 Webhook notification 服务。
|
||
//
|
||
// 职责边界:
|
||
// 1. 在 sv 层完成 internal/feishu provider 装配,cmd 入口不直接依赖 internal 包;
|
||
// 2. 只组合 notification 领域内部依赖,不连接数据库、不读取配置;
|
||
// 3. provider 构造失败时直接返回 error,避免启动出半初始化服务。
|
||
func NewNotificationServiceWithFeishuWebhook(recordStore RecordStore, channelStore ChannelStore, providerOpts FeishuWebhookProviderOptions, serviceOpts ServiceOptions) (*Service, error) {
|
||
provider, err := notificationfeishu.NewWebhookProvider(channelStore, notificationfeishu.WebhookProviderOptions{
|
||
FrontendBaseURL: providerOpts.FrontendBaseURL,
|
||
})
|
||
if err != nil {
|
||
return nil, err
|
||
}
|
||
return NewNotificationService(recordStore, channelStore, provider, serviceOpts)
|
||
}
|