关闭。这个问题是opinion-based .它目前不接受答案。
想改进这个问题？更新问题，以便 editing this post 提供事实和引用来回答它.
6 个月前关闭。
Improve this question
如何在 Scala 项目中组织代码？
经过多年的 Java 开发(大部分时间使用 Spring)，我们试图在 Scala 中创建一个快速原型(prototype)。
出现的第一个问题是:我们是否会基本上使用相同的包名称和代码组织，并且只用 Scala 编写代码？
例如，我们习惯于为我们的实体(AccountHelper、CacheHelper...)提供帮助，有时我们也使用服务(AccountService...)。
ot:在更远的地方，我们还将研究如何将我们的 maven 子模块移植到 sbt，但这完全是另一回事。
最佳答案
答案部分取决于对您来说最重要的是什么。如果您对快速原型(prototype)部分真的很认真，那么就物理文件/目录布局而言，我会从一个平面文件开始，只有在有足够的代码使之变得尴尬时才开始分解它。这至少应该使您的代码的全局重组更容易，直到您获得正确的整体结构。 Scala 不强制执行包:目录、类:文件的对应关系，并且考虑到 Scala 的简洁性，无论如何这在许多情况下都可能是多余的。
一旦结构正确，在物理分解之前，没有什么可以阻止您将内容组织到一个文件中的多个包中。实际上，当您需要时分解文件应该非常容易。
你没有多说你的Helper & Service类确实如此，但从命名约定来看，它们听起来像是通用(又名参数)特征或类的良好候选者。这将允许您分解出所有不同 Helpers 的共同点(对于服务也是如此)。它们应该有一些共同点来证明命名约定的合理性。然后，您最终会使用或可能扩展类型，如 Helper[Cache]和 Service[Account] .我还猜测这些类型的实例很少，范围相当广泛，并且可能会从隐式传递中受益，从而使 Helper[_]和 Service[_]进入类型类。此时您也可能不再需要 Spring，因为隐式查找可能会为您提供所需的依赖注入(inject)。但是，我只是通过您提供的几个类名并阅读了很多内容，因此我很可能完全不在此列。
另一种可能性是，像 Helper 和 Service 这样的辅助类只是变相的闭包。这是 Java 中此类类的常见情况。在这种情况下，您应该在 Scala 中将它们实现为函数，但我再次只是从名称中猜测......
您还可以查看 Layer Cake 模式，看看这对您的项目是否有意义。
与我过度活跃的想象中的这些产品相比，有关您的项目的更多信息可能会为您提供更好的建议:)。
Hera 是一些可能有用的链接:
关于Scala 项目组织，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16652869/