问题描述
在考虑端口和适配器架构时，我担心过度设计我的代码。
系统与外界联系的两个非常常见的例子是我的HTTP 堆栈和本地文件系统。这些是应用与外部世界接触时的明显情况，测试需要一定程度的控制和/或模拟。
我的第一个想法是：“也许我应该有一个中央服务或单例，并确保任何 HTTP 调用都通过它”
对于测试来说，这将是惊人的，因为我可以强制任何测试崩溃，如果对外部世界的意外调用是在没有模拟或至少是开发人员明确的音乐会的情况下完成的。这也标准化了模拟 HTTP 调用的单一方法。
另一方面，感觉就像我在重新发明轮子。我是一名 Javascript 开发人员，本机库不太好。大多数人使用第三方库，该库将作为整个项目的依赖项传播。
我目前的方法是重新发明轮子。我确实创建了抽象层（服务单例），但使用第三方库保持轻量级。目标是尝试使用薄的自制外观在项目中“包含”第 3 方库代码的传播。显然，范围更大的东西是个例外。例如，将数据库访问抽象化往往会带来更多痛苦而不是荣耀。
对HTTP 和本地文件系统访问 的自制抽象是端口/适配器的明显例子还是只是过度设计？
解决方法
这种困境（为 http 访问创建您自己的“网关”）必须在可重用性和 DRY 方面做得更多，而不是六边形架构。
六边形架构表示“在您的应用中放置一个与技术无关的端口，用于与外部世界项目对话，然后在您的应用外放置一个 http 适配器，用于翻译”。
关键是...你有很多带有 http 适配器的应用程序吗？在这种情况下，将 http 适配器抽象为一种自定义网关可能是值得的。