小编Nat*_*han的帖子

我已经启动了许多Phoenix项目，但我总是发现正确定义Contexts具有挑战性。我经常最终在上下文中创建“子上下文”，我认为这很好，但它从来都不是完美的。

我的问题是人们对于定义 Phoenix 上下文有什么建议？或者某种在上下文之间划线的试金石。

举个例子：

我有一个与 Slack 的 API 集成的应用程序，并使用 Google 的地图 API 查找时区/位置信息，并使用 Stripe 进行付款。

1. 我从 Slack Context 开始，但很快发现我将 Slack API 逻辑与应用程序的实际业务逻辑混合在一起。
2. 我将所有 Google 地图内容放在 Google Context 下
3. 我将所有 Stripe 内容放在 Payments Context 下

此时我基本上是通过第三方工具分离上下文，但最终得到了过于臃肿的 Slack 上下文。一旦应用程序建立起来，重新构建一个人的观点并重新定义上下文也具有挑战性。