最近、私は複雑なロジックコントローラを構築していましたが、これは「単一責任」の原則のためにリファクタリングしたかったのです。だから私はサービスについて読む。しかし時には私は懸念を見ました。私はそれがルビーのサービスの代わりであるが（デフォルトのサービスフォルダなどがないため）、「懸念とサービス」などの良い記事は見つかりませんでした。懸念事項とサービス
コントローラーのモデルやサービスについては、それでもなお、これを証明しているトピックや記事は見つかりません。
サービスと懸念の違いとその使い方について誰でも説明できますか？
懸念事項とサービスは、非常に全く異なる目的で使用される抽象パターンです。
私はユーザーを認証したいと言います。これを私は、単一のクラスでの認証のためのロジックのすべてをカプセル化する手助けは別に
class AuthenticationService
def initialize(username, password); end
def run(); end
end
：私だけで簡単にauthenticate(username, password)機能を書くことができますが、代わりにクラスで、その関数のロジックをカプセル化するために有用であるかもしれません他の認証クラスを作成することができます。
class GoogleAuthenticationService
def initialize(username, password); end
def run(); end
end
class FacebookAuthenticationService
def initialize(username, password); end
def run(); end
end
一方、モジュールの機能を別のクラスに混在させることに懸念があります。ユーザーに権限を与えることに関係していたRailsコントローラがあるとします。ユーザーが承認されているかどうかを確認するbefore_actionを実装する懸念を書くかもしれません。次に、認可チェックを実施したいコントローラにその懸念事項を混在させることができます。
懸念事項は基本的に、モデルの側面を別々のファイルにカプセル化してコードを上書きするためのモジュールです。利点は、ActiveSupport：Concernモジュールから継承されるため、懸念事項が含まれるモデルの検証や関連付けなどのActiveRecord操作にアクセスできることです。
サービスオブジェクトは、主にメソッドをオブジェクトにラップするために使用されます。これらは、ロジックを小さな再利用可能なコンポーネントに分割するのに便利です。これらは、デカップリングシステムやシステムの理解を容易にするためによく使用されます。なぜなら、基本的に何種類かの多目的クラスから、単一の目的で多くのクラスに移行するからです。
私は懸念事項について懸念しており、注意を払うことに注意しています。
Fnyさんの答えが書いている間に私に表示されました。私は受け入れられた答えであると思います。