(ruby on rails)モデルにどこまでの責務を持たせればいいかが分からない

Question

自身のスキルアップの為に最近はソフトウェア設計、オブジェクト指向(OOP)に挑戦してます。ネットで調べつつ、自身の制作物に適用させています。

オブジェクト指向には単一責任の原則なる言葉があると思います。
単一責任の原則は参考記事によると

変更する理由が同じものは集める、変更する理由が違うものは分ける。

クラス（オブジェクト）が担う責任は1つに限定すべきである（かつその責務は完全にカプセル化されるべきである）。

また参考記事2によると

1つのクラスは1つの仕事しかしない

だそうです。
基本的にクラスというものは属性と振る舞い(メソッド)を持ち得るクラスで、且つモデルクラスはビジネスロジック(概してそのモデルが参照するテーブルの属性に対するCRUDを行う？)を書くべきクラスだと考えています。(ActiveRecordは属性を書かなくてもいいので便利ですね)
勿論例えばActiveRecordモデルクラスでwebAPIに対してリクエストを投げる処理を書かない等分かりやすいものは分かるのですが、例えば

class TApplicant < ApplicationRecord
  belongs_to :t_work
  belongs_to :t_user_account

def apply_works(user_id, work_id)
TApplicant.create(t_work_id:work_id, t_user_account_id:user_id)
end

def self.countapplicant(work_id)
self.where(t_work_id: work).count
end
end

以上のように、とある仕事に応募する(TApplicantテーブルにユーザーを登録する)メソッドと登録者数を集計するメソッドがあるとします。
どちらもTApplicantモデルに関わり何らかの処理を行うメソッドですが、片方はCRUDのCを行い、もう片方はマッチする条件をカウントしているだけのメソッドです。
単一責任の原則に照らすと、要素カウントするメソッドを書くのはアウトなのかもしれませんが、正直コード数が少ない上にTApplicantクラスに対して無縁のメソッドでは無いと思います。

このような場合でもクラス分けして責務を分離させるべきなのでしょうか？
このようなオブジェクト指向の話となると、比較的プレーンなrubyのクラスの話が多いので、railsではどうするべきなのか迷っています。
よろしくお願い致します

Answer 1

規模の小さいプログラムでは、CRUD を一つのクラスにまとめておくというのも良くやると思います。

クラス設計にはこれが正解というものが存在せず、結構センスが問われるので難しいところだと思いますが、あまり冗長になりすぎないようにするのも大切です。

提示していただいたコードも、これだけを見ればそのままでも悪くないと思います。

ただし、規模の大きなプログラムになると、全体の設計を考慮する必要があります。
今は小さなクラスでも将来的に拡張される可能性もありますので。

Answer 2

workとuseをつなぐためだけのクラスなので、あまり気にしないと思います。
それよりもworkやuserのクラスの方が重要な気がします。
idddなんかを読むと、少し世界が開くと思います。