在Swift中使用Clean Architecture的外部依赖关系

与你们中的许多人一样，我们一直在为GDPR做最后的冲刺。

而且我们意识到我们的应用程序与外部SDK有很多依赖关系 。 市场营销需要新的跟踪， 导入SDK-A 。 我们需要深度链接， 导入SDK-B ，我们还需要跟踪广告， 导入SDK-C ，有关应用程序通知的信息… SDK-D …

🐞问题

所有这些花哨的SDK给我们带来了很多问题

• 您见过这样的AppDelegate吗？

  func appDidFinishLaunching ... { 
  Firebase.setup（“ 32FD-324AFF-12FD4D”） 
  Firebase.logLevel = .verbose 
  AnotherSDK.start（） 
  AnotherSDK.startSomething（） 
  AnotherSDK.disableSomething（） 
  AndAnotherSDK.doAnotherConfiguration（） 
 返回真 
  } 

• 如果我们有一个新的Swift版本，我们需要等到所有这些SDK更新之后。
• 使用Cocoapods时，干净的编译可能会花费很长的时间，因为我们需要重新编译所有这些漂亮的依赖项。
• 我们决定使用SDK-A，在没有真正注意到的情况下，我们50％的类都在使用SDK-A的API。 如果SDK-A的所有者决定关闭此漂亮的工具怎么办？ 它还将关闭我们的应用程序！

我们都是这些SDK的奴隶！

更有趣的是：使用GDPR，用户必须控制所有这些SDK。 等一下，不要和市场营销人员打架！

🏆清洁建筑

是时候为这些混乱带来一些秩序了。

外部依赖项需要成为我们应用程序的插件！

应用程序使用Crashlytics，Appsee，控制台报告崩溃，将其存储在文件中或将其打印在纸上并不重要 。 这些只是细节。

💉依赖注入

因此，让我们开始构建一个我们可以注入的协议（因此可以在单元测试中对其进行模拟。）

⚙️模块

请务必注意， 唯一的公共API必须是ExtenalDependenciesInjection。

因此，我们可以将整个实现带到另一个模块中。 之后，我们可以将该模块导入到我们的应用中。 甚至在许多应用程序中重复使用此模块。

因此，我们不必经常重新编译所有这些外部依赖项。 您的编译时间将更快，CI服务器也会更快。

结果，如果SDK-A决定更改API，请关闭它或将所有内容报告给NSA。 我们可以超快地替换它🤘

🚀结论

• 我们可以运行我们的应用程序而无需所有这些依赖项。
• 无需所有这些依赖项就可以轻松地对我们的应用程序进行单元/用户界面测试 。
• 我们可以对每个SDK的实现进行单元测试 。 因此，我们可以证明错误不是我们的错。 并告诉老板： SDK无法正常工作！ 😎
• 现在， 禁用/启用任何SDK都非常容易。
• 我们可以随时替换所有这些依赖项。
• 不必每天重新编译所有这些依赖项20次。

不要依赖任何人。 不要与市场营销人员打架。 如果不再支持一个SDK，请不要惊慌。 不要喂饱SDK的泡沫。 清洁建筑在这里拯救我们所有人！

外部依赖项必须只是插件