システム設計の落としどころ

システム設計の落としどころ

システム設計の落としどころを考察してみた

PHPベタ打ちのころから、私の設計スタイルは作りながら改善です。
Laravelで新設するシステムでも同じ形で設計していて、やはり悩むポイントも同じところです。

『アレもやりたい。コレもやりたいをどうコントロールするか』

システムを外注すると「それは当初話してませんでしたよね。金額変わりますけどいいですか?」なんて言われますが、自分で作ってると機能追加したくなるものです。そして、機能追加で使いにくくなることも屡々。

と言うことで、システム設計の落としどころについて考察してみます。

追加機能の管理をどう設計するか

機能を追加すると必ずその管理タスクが必要になります。
その際、リレーション値やフラグ値が多いと管理が面倒なものになり更新(利用)頻度が大きく下がります。

これをクリアするために以下4点を検証します。

  1. 追加機能の管理方法
  2. 関係する情報の更新で段取りが増加しないか
  3. 機能が増える事で条件分岐が複雑にならないか
  4. CSVなどでの更新で不必要な条件が発生しないか

上記条件全てに合致する場合は追加機能そのものの利用度から見直した方がいいかもしれません。
意外と代替案は出てくるものです。

例えば、商品名をモール毎に変えたいとします。
モールAではid=1の商品名、モールBではid=2の商品名と言った具合です。

テーブル的にはとても簡単に構築できますが、モールA、モールBの商品名である事がテーブルだけでなく、画面上でも理解できないといけません。条件分岐が複雑な場合、画面に表示させなくてはいけない項目数が増えパッと見て操作できるシステムから解離していきます。

追加機能はどうコントロールするか。画面回りも含めて検討しなくては結論が出ません。

まとめ

【至れり尽くせり】に構築した場合、条件分岐が複雑になる事がしばしばあります。
A・B・Cの値が揃わないとデータが宙ぶらりんになるとか。

この状態でよく起こる事は『操作したつもりになっていて(条件が不足して)実はできていない』です。
管理が散らばり煩雑になる訳です。

こんな時の逃げの一手は【デフォルト値を決めておく】です。

『Bに値が無い時は1だと思ってね』
そんな仕掛けをしておけば何とかなります。

欲しい機能を追加したい、でもすべてに必要な値じゃないし。
そんな時は『デフォルト値を決めて構築する事』が意外と落としどころになってきます。