在应用程序代码中，外发请求的决策逻辑应该放在哪里？
1 分•作者: siva_CEO•6 个月前
在我参与的几个系统中，应用代码会构建发送给外部服务（API、AI 服务、合作伙伴系统）的请求。<p>在发送之前，我们经常需要决定一些事情，例如：
这个请求应该原样发送吗？
应该删除或修改某些内容吗？
或者应该完全停止这个请求？<p>目前，这种逻辑往往分散在各个地方：
应用代码中的内联检查
通过代码审查强制执行的约定
对未针对此层设计的安全工具的部分复用<p>我很好奇其他人从架构角度如何处理这个问题：
你们会将这种决策逻辑集中在某个地方吗？
还是将其保留在每个应用附近更好？
你们见过哪些随着系统发展而经久耐用的模式？<p>我正在寻找架构方面的观点和实际经验，而不是工具推荐。
查看原文
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.