出站请求的决策逻辑应该在应用代码的哪个位置？
在我所工作的几个系统中，应用程序代码会构建请求并发送到外部服务（API、人工智能服务、合作伙伴系统）。在发送请求之前，我们通常需要决定以下事项：
- 这个请求是否应该原封不动地发送？
- 是否需要删除或更改某些内容？
- 或者这个请求是否应该完全停止？
目前，这种逻辑往往分散在不同的地方：
- 应用程序代码中的内联检查
- 通过评审强制执行的约定
- 部分重用并不适用于这一层的安全工具
我很好奇其他人在架构方面是如何处理这个问题的：
- 你们是否将这种决策逻辑集中在某个地方？
- 还是更适合与每个应用程序紧密结合？
- 随着系统的发展，你们有没有看到一些经得起时间考验的模式？
我希望获得架构方面的见解和真实的经验，而不是工具推荐。
查看原文
In several systems I work with, application code builds requests that are sent to external services (APIs, AI services, partner systems).<p>Right before sending, we often need to decide things like:
should this request go out as-is?
should something be removed or altered?
or should the request be stopped entirely?<p>Today this logic tends to live in scattered places:
inline checks in application code
conventions enforced via reviews
partial reuse of security tools that weren’t designed for this layer<p>I’m curious how others approach this from an architecture perspective:
Do you centralize this decision logic somewhere?
Or is it better kept close to each application?
Have you seen patterns that age well as systems grow?<p>Looking for architectural perspectives and real experiences, not tooling recommendations.