如何在现实世界的 Go 项目中分离路由、处理程序、第 3 方接口和业务逻辑

Question

看完后官方指导如何组织项目，并通过各种准备（1，2，3仅举几例）的例子和项目，我不禁怀疑是否我的结构化方法我的REST的API的服务器应用程序的结构正确。API 的用途是什么？邮政 /auth/sign-in接受usernameandpassword并发出JWT (JSON Web Token)。得到 /auth/sign-out将 JWT 添加到黑名单以使身份验证会话无效。得到 /resources检索所有资源的列表。POST /resources（需要有效的 JWT 身份验证）接受 JSON 正文，创建新资源并向所有人发送有关新资源的电子邮件和通知。我的项目是什么样的目前我没有创建任何库。一切都在主包中，带有路由的总体服务器设置等都在main.go. 我没有去寻找 à la Rails 或 Django 的 MVC 模式，以避免仅仅为了它而使事情变得过于复杂。另外我的印象是它并不真正符合上面已经提到的指南中描述的命令和库的推荐结构。auth.go # generates, validates JWT, etcauth-handler.go # Handles sign-in/out requests; includes middleware for required authenticationmailer.go # Provides methods to send out transactional email, loads correct template etc.main.go # set up routes, runs server; inits mailer and notification instance for the request contextmodels.go # struct definition for User, Resourcenotifications.go # Provides methods to publish push notificationsresource-handler.go # Handles request for resources, uses mailer and notifications instances for the POST request它应该是什么样子？路由应该分开吗？中间件呢？您如何处理与 3rd 方代码的接口 - 想象一下mailer.go在概述的示例应用程序中与 Mandrill 和notifications.goAmazon AWS SNS对话？