プログラミングにおいてモデルを作る時は、大体何か一つのモノを表すモデルを作ります。何か一つというのが曲者でして、含意の広い一つのモノを対象にモデルを作るとコードが肥大することがあります（含意すべてを入れても小さい場合や共通処理から外れない場合があって、そういう時は問題が起きなかったり）。この分割の仕方にライフサイクルの観点から分割する方法があります。 モデルはある範囲のモノを抽象化して表現します。これを具象化してオブジェクトを作成する際、オブジェクトの操作を実行した後に保存する際にそれぞれ処理が入ります。ファイルシステムやデータベースに保存されている情報を表すモデルの場合は特にこれが顕著です。下図はEric Evans. エリック・エヴァンスのドメイン駆動設計 (Kindle の位置No.3058). 翔泳社. Kindle 版. からの引用図です。
正直、図の完成度が高いです。モデルが肥大する兆候が見えたら図の矢印ごとに分割するだけでかなり整理できます。
記事が短いので以下例の様なものを書きます。例ではDB（データベース）には既に値があり、保存はDBに行うと考えます。上図の再構成、格納、修正の部分を取り扱います。DBの一語だけであるモデルに関することを全てモデルの一クラスに記述すると破綻しそうなのが想像できます。少なくとも、再構成の際にDBへの問い合わせ方法（FROM table、PDOなど）が必要になり、柔軟な検索条件の取り扱いも高頻度で必要になります。格納の際にもDBで行えないバリデーション、複数の関係するデータについての同期が必要になります。これらの上でモデル自体の振る舞いについても必要になります。分割が必要です。
DBの例では問い合わせ、格納、振る舞いの三分割ができます。フレームワークが備えていることの多いORM（オブジェクト関係マッピング）においては大体、問い合わせが隠蔽されています。データベース定義とコード内容を分離させたい際にのみ生成に関する追記が必要になるでしょう。格納もDB命令部は隠蔽されがちで関係設定が定義されいれば勝手に同期してくれます。バリデーションのみが必須です。ルールが複雑化する場合、あるルール一つを表すモデルを作るのもいいでしょう。残ったのは振る舞いです。これはアクティブ状態で直に参照できない方が問題の部分であり、インスタンス化されたモデルの本質といっていい部分です。
