Serviceクラスとユーティリティクラスまたはヘルパークラスの違いを知りたいのですが。基礎となるメソッドのみを含むクラスがdaoを呼び出すのはサービスですか?ヘルパークラスの使用はSRPに違反していませんか?
線は少しぼやけている可能性がありますが、私はこのように見ています:
Serviceクラス/インターフェースは、クライアントがアプリケーションのいくつかの機能と対話する方法を提供します。これは一般的にパブリックであり、ビジネス上の意味があります。たとえば、TicketingService
インターフェイスを使用すると、buyTicket
、sellTicket
などを実行できます。
ヘルパークラスはクライアントから非表示になる傾向があり、ビジネスドメインの意味を持たない定型的な作業を提供するために内部的に使用されます。たとえば、特定のデータストアに保存するために日付をタイムスタンプに変換したいとします。この処理を実行するDateConvertor
メソッドを備えたconvertDateToTimestamp
というユーティリティクラスがある場合があります。
サービスは単にDAOと密接に結びついているのではなく、永続性よりも広い用語/使用パターンです
ヘルパークラスは、その原則に従ってコーディングされていれば、SRPに違反しません。つまり、各メソッドは1つのことと1つのことをうまく行う必要があり、クラスは1つのタイプのユーティリティヘルプ(日付変換など)を実行し、それをうまく行う必要があります。
科学的な定義ではありませんが、私の一般的な見方では、サービスクラスにはアプリケーション内にコンテキストがありますが、ヘルパーはより一般的で、どのアプリが支援しているかは気にしません。
私にとって、私は次のような Eric Evansのservice
の定義に従います。
一般に、適切に設計されたシステムでは、ほとんどのクラス(ドメインモデル内)は、モデル内の特定のエンティティまたはエンティティセットを処理するという点で、明確な責任または機能を持っています。
つまり.
特定のエンティティに属さない機能がある場合、適切な場所を見つけるのが難しい場合があります。つまり、Account
とCustomer
の両方を含むプロセスをカプセル化するものです。
つまり、ここでservice
の出番です。ドメインモデルにあるが、あるエンティティ/コンポーネントまたは別のエンティティ/コンポーネントには本来属さないコードを配置する場所です。
helper
は一種の戦略クラスと考えています。私にとっては、さまざまなクラスで再利用する必要があるが、それを使用するクラスの階層内に抽象メソッドとして適切に配置できないコードを配置する場所です。個人的に私はhelper
という用語を少しあいまいにしており、私のモデルには実際にはありません。それらは私が使用するライブラリに存在しますが。
サービスクラス: ビジネスロジックが含まれています。
ヘルパークラス: このクラスは、再利用可能なコンポーネントの1つです。
関連のない2つのプリンシパルを混同しています。サービスとヘルパークラスは接続されていません。特に「サービスクラス」という用語は誤解を招く可能性があります。クラスよりも抽象化のレベルが高い「サービス」を指していると思います。サービスの特徴は
「1つまたは複数の機能へのアクセスを可能にするメカニズム。アクセスは、規定のインターフェイスを使用して提供され、サービスの説明で指定された制約とポリシーに従って実行されます。」
この定義は、状況に応じて少し異なります。ただし、重要な点は、「サービス」という用語が抽象的なレベル、つまりアーキテクチャとドメインの知識のレベルにあるということです。 「ヘルパークラス」は、一般的な操作をカプセル化するクラスを参照する設計パターンです(ブロブクラスまたはゴッドクラスに進化する傾向があるため、アンチパターンです)(これは抽象化アプリケーション/ソリューションの知識)に接続されています。ヘルパークラスを含まないソフトウェアはほとんど存在しないという事実を知っていますが、それでも悪い習慣です。
注意すべきことの1つは、DDDでの「サービス」の複数の定義です。
アプリケーションサービス:これらはアプリケーション層にあり、ドメインおよびデータ層と通信します。これらは、外部システム/ UIがDDDシステムと対話するためのインターフェースです。
ドメインサービス:これは、ドメインまたはアプリケーションレイヤーで使用でき、1つの特定のエンティティに適切に適合しないビジネスロジックを含みます。
インフラストラクチャサービス:ドメインが外部リソースと通信するために使用します。
ヘルパークラスには、複数のエンティティによって再利用されるコードやアルゴリズムが含まれる傾向があるため、DRYの原則に違反しない限り、エンティティに入ることができません。これらは、おそらくドメインサービスに最も近いものです。ソートは同じ目的(エンティティーからのビジネスロジックの外部化)を満たしますが、理由は異なります。