追記はてブで何人かの方にご意見いただきましたが、「モデル」という言葉がDDDで言うところのドメインモデルDDDで言うところのエンティティ(ドメインモデルの一部)Railsが生成するActiveRecord::Baseを継承したクラスの3つの意味で使ってしまっていて、多くの方を混乱させてしまったようです。上から順に「ドメインモデル」「エンティティ」「AR継承クラス」と表記を変更しました。みなさん、ご意見ありがとうございます。いうのでいう「サービス」まで含めてモデルだしこういうの書くやつはなんもわかってないみたいの延々と言っていきたいというわけで、記述を変更しました。オートロードは勝手にされるはず。serviceもformもModelなわけだからapp/models/servicesに置いてService::MemberRegistrationとかにしたい。確かにapp/modelsの下に置けばオートロードされるのですが、そこにはActiveRecord継承クラスが配置されてしまっている既存のアプリケーションを想定していて、そこにできるだけ影響を与えずに全く違うディレクトリにサービスを配置したいと思ったのです。説明が漏れていてすみません。あとフォームはモデル(=ドメインモデル)ではない認識なんですが違いますか?あくまでユーザーイターフェースの都合で導入したもので、受け取ったパラメータの加工だけを責務とするイメージです。ドメインロジックを持たない感じですね。「railsにサービス」って言い出す人の99%は、「処理を逐次的に書かないと理解できない」の言い換えだと疑って掛かってる。サービスの次に言い出すのは、だいたい「複合キー」。オブジェクト指向大好きですし、あまり手続き型じゃないと理解できないわけじゃないのですが、どのあたりでそう思われたのでしょうか?ご教示いただけると幸いです。それともここで言う「逐次的」の対義語は「オブジェクト指向」ではないのですかね?また複合キーについても差し支えなければもう少し詳しく教えていただければ嬉しいです。DDDのサービスはドメインモデルの「中」にあって、特定のエンティティに属さない処理を実行するオブジェクトのことを主に指すので、多少意味のズレを感じる。さんと同様の指摘ですね。言葉の使い方が曖昧ですいません。後者のアプリケーション層の責務については理解しているつもりです。「ある振る舞いをエンティティに持たせるか、サービスにするか」を判断するときに、それがインフラストラクチャレベルでどれだけ多くのリソースにまたがるかを判断基準として使ったりするので書かせていただきました。多くのリソースにまたがっているほどそれだけ多くのことをアトミックにやる必要がある、ということなので。業務分析の結果としてエンティティの振るまいかサービスか判断するのが鉄則だとは思うのですが。Model」と呼ばれていますね。*2:ActiveRecordを継承したものと必ずしも一致しないので注意。ドメインモデルエンティティは論理レベルでちゃんと実装すること。「ビジネスの構造を扱うアーキテクチャとユーザとの接点...タイトルの通り、登壇してきました。イベントページはこちらで...2015-03-25そろそろドメイン駆動設計はもうちょっとだけ細分化されるべき昨日飲みながらドメイン駆動設計(以下、DDD)についてしゃべっ...2015-03-13ソフトウェアプロセスは人に依存するようになったこれを読んでなんとなく思ったことを書く。見極め方Archiveスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。