とある Rails アプリ開発チームの設計手法??


最近、場当たり的な対応ばかりで、チームメンバーらに日頃指摘されていることを、自戒の念をこめて自分なりにまとめてみた。


なので、一般的な話でない or 勘違いが含まれていますのでご注意を。


まず、まとめ。

  • 要望や要件をリソースに対する CRUD に分解する
  • リソースの粒度を決定する
  • リソースの実現方法を決定する
  • CRUD の実現方法を決定する

まず、入力として例えば「ソーシャルブクマが欲しい」という要望があった場合、以下のように分解します

  • ブクマを作成する
  • ブクマを一覧する
  • ブクマの詳細を見る
  • ブクマを編集する
  • ブクマを削除する

この際に、CRUD に分解できないものは、できないものとして別途扱う。


で、次に粒度を確認します。


例として挙げた「ソーシャルブクマ」だと、自分のブクマ以外を扱いたいかと思うので、例えば、こんな感じか??

  • 他人が登録したブクマ
  • みんなのブクマ
  • タグ付けされたブクマ
  • プライベートなブクマ
  • and more

で、どこまで必要かをプロダクトオーナーと確認する。


あとは、各リソースを ActiveRecord なモデルとするか、ActiveResource、ただの Presenter とするか、次に CRUD をどういった画面で実現するかに落しこんでいけばいいと思う。


と、日々できていないことの理想形として、ざっとまとめてみた。


CRUD の数と画面の複雑さがシステムの規模の重要な因子になってるので、割と今の自分の
感覚に近い気はする。


けど、こうやってまとめてみると、そもそも設計手法でもないし、ごくごくフツウの事ですなww