答えは、あなたにとって何が最も重要かによって部分的に異なります。クイック プロトタイプ部分に真剣に取り組んでいる場合は、物理的なファイル/ディレクトリ レイアウトに関しては、1 つのフラット ファイルから始めて、それをぎこちなくするコードが十分にある場合にのみ分割を開始します。これにより、全体的な構造が正しくなるまで、少なくともコードのグローバルな再構築が容易になります。Scala は、package:directory、class:file の対応を強制しません。Scala の簡潔さを考えると、多くの場合、やり過ぎになる可能性があります。構造が正しくなったら、物理的に分割する前に、1 つのファイル内で物事を複数のパッケージに整理するのを止めるものは何もありません。必要なときに実際にファイルを分割するのは非常に簡単です。
あなたのHelper
&Service
クラスが何をするかについてはあまり言いませんでしたが、命名規則からすると、それらはジェネリック (別名パラメトリック) トレイトまたはクラスの良い候補のように思えます。これにより、すべての異なるヘルパーに共通するもの (サービスについても同様) を割り出すことができます。命名規則を正当化するために、かなりの共通点が必要です。その後、 やなどの型を使用するか、場合によっては拡張することにHelper[Cache]
なりService[Account]
ます。Helper[_]
また、これらの型にはかなり広い範囲のインスタンスがほとんどなく、暗黙的に渡されることで恩恵を受ける可能性があると推測しています。Service[_]
型クラスに。暗黙的なルックアップによって必要な依存性注入が提供される可能性があるため、この時点で Spring が不要になる可能性もあります。ただし、提供されたいくつかのクラス名を使用して、非常に多くのことを読み込んでいるだけなので、ここでは完全にベースから外れている可能性があります。
もう 1 つの可能性は、Helper や Service などの補助クラスが単なる閉鎖であるということです。これは、Java のそのようなクラスではかなり一般的なケースです。この場合、Scala で関数として実装する必要がありますが、名前から推測するだけです...
また、Layer Cake パターンを調べて、それがプロジェクトにとって意味があるかどうかを確認することもできます。
あなたのプロジェクトについてのより多くの情報は、おそらく私の過剰な想像力のこれらの製品よりも良いアドバイスを得るでしょう :)
Hera は、いくつかの潜在的に役立つリンクです。