Open2

値オブジェクトについて

toketoke

住所や電話番号など、他のモデリングでも出てきそうな概念で、共通のルールになりそうなものを、一つのクラスに閉じ込めて、共通化する方法。
https://zenn.dev/kingdom0927/articles/541488efc03a24

メリットとして、ロジックが飛び散らなくなる。

railsの大規模開発では、頻繁に業務ルールが変更し、その際に簡単に対応できるようにするために、
値オブジェクトやconcernの活用、フォームオブジェクトやデコレーター層の利用、クエリオブジェクトやコマンドオブジェクト、バリデーター層(共通のDBのバリデーション)、exceptionクラスなど、色々責務を分けて、モデルの肥大化や、ドメインモデル貧血症にならないための仕組みをみんなで考えている

toketoke

一番大事なのは単一責任の原則かも。
このクラスの役割は何ですか?このメソッドの役割は何ですか?に一言で答えられるのが理想。
ただ、ユースケース層のような、色んなクラスのオブジェクトを利用する系のやつは、「これを実行すると、このユースケースが実現できます」になるが、ユースケースに固有のロジックをあまり書かないようにしないといけない。
ユースケースに書くと、再利用しにくいし、ドメインモデル貧血症になりやすい。

本当の理想はモデルの役割をリポジトリとエンティティに分けるべきだが、railsではデフォルトでは一緒になっているので、DBへの問い合わせとビジネスロジックが一緒になる問題がある。
が、ユースケースにはあまりビジネスロジックは書かない方が良い。
ユースケースからユースケースは呼ばない方が良い。
ユースケース同士が依存してしまうので