Lambda 弹球

虽然无服务器架构对解决一些问题非常有用，但它们确实有一定的复杂性，尤其是当它们涉及到复杂执行和跨多个相互依赖的 Lambdas 的数据流时--这有时会导致所谓的 Lambda 弹球架构。我们团队发现维护和测试 Lambda 弹球架构可能非常有挑战：理解基础设施、部署、诊断和调试都会变得困难。在代码层面上，根本不可能将领域概念和所涉及的多个 Lambdas 之间做简单映射，这使得任何改变和添加都具有挑战。尽管我们相信无服务器是适合某些问题和领域的，但它并不是每个问题的 "万能解法"，这就是为什么你应该尽量避免陷入 Lambda 弹球。一种有助于解决这个问题的方法，就是区分公共接口（public interface）和已发布接口（published interface），并在它们之间应用带有已发布接口的领域边界。

在项目中构建无服务器架构的这几年，我们注意到落入一个分布式单体应用的陷阱是一件很容易的事情。当请求在日益复杂的云服务中不断跳转时，深陷Lambda、存储桶与队列中的Lambda弹球架构明显无法看清重要的领域逻辑，通常只能对应用整体进行集成测试，而很难进行单元测试。为了避免陷入弹球架构，我们可以明确区分公共与发布的接口，沿用良好的领域边界，并在其间使用已发布的接口。