こんにちは。最近はクライアント側のjsばかり書いているぷーたんです。
今日はありがちな例を交えて、ビジネスロジックの分離について話します。
伝えたいこと
- ビジネスロジックはUIから分離しよう
そもそもビジネスロジックって何？
- そのサービス、プロダクトの根本的なルールや制約（ビジネスルール）を表現したコード
- コードの複雑さの核心部分でもある
詳しくは後ほど記載します。
なんで分離したいの？
- 更新の根拠や頻度が違う物を分けることで、更新やリリースがしやすくなる
- UI/UXの改善時に余計なことを考えずに実施できる
事例： 意外と混ざりがちなビジネスルール=上限数
ピザのweb注文フォームの開発を考えてみます。次のようにビザのサービスが成長していくとします。
- 初期はトッピングは2個まで選べる。
- ピザが順調に売れていく中で、利率の高いミックスピザを推していくことになり、施策としてミックスピザの時だけトッピングを3個まで選べるようにすることになった。
- 水曜日の売り上げが悪いことがわかり、水曜日にはさらにトッピングを1つ追加できるようにすることになった。
- 3の効果が薄いので、水曜日のトッピング枠を目立つようにする。
全てコンポーネントに実装した場合
ではコードを書いてみます。（ここでは私が慣れているreactで書きます）
- https://codepen.io/putan/pen/rNeLPzo
- https://codepen.io/putan/pen/oNxLmEX
- https://codepen.io/putan/pen/WNwxmoL
- https://codepen.io/putan/pen/WNwxmVN
差分をみてみると maxCount の式がどんどん複雑になっているのがわかります。
1-2. https://gist.github.com/putan/bd460d496d0d957560c625bca67e88b7
2-3. https://gist.github.com/putan/a3c0c407e807a1c30073b7d0a1e58342
3-4. https://gist.github.com/putan/aacc3dea7d61b534fb7d8e75885f33e8
maxCountの差分を抜粋
/* 1 */ const maxCount = 2;
/* 2 */ const maxCount = props.pizza === 'mix' ? 3 : 2;
/* 3 */ const maxCount = (props.pizza === 'mix' ? 3 : 2) + (props.isWed ? 1 : 0);
ビジネスロジックを分離した場合
次はPizzaクラスを作り、トッピングに関するロジックをそちらに分けて作ってみます。
//---は別ファイルという程で書いています。
- https://codepen.io/putan/pen/ExKyJBd
- https://codepen.io/putan/pen/BaKzeNQ
- https://codepen.io/putan/pen/vYGKwZL
- https://codepen.io/putan/pen/LYNZozY
1~2~3では全体（主にクラス）に修正が入りますが、4ではコンポーネントだけが更新されているのがわかります。
1-2. https://gist.github.com/putan/0b9051fab909fae866b7446b88ff47b0
2-3. https://gist.github.com/putan/18be63e3333f2ee7ee9a3fe23aad2fa3
3-4. https://gist.github.com/putan/ce108df7a62d98b759fdbce80a342193
比較してわかること
1~2~3の施策は「ピザを売るというサービスにおける制約」の変更であり、まさにビジネスルール&ロジックがビジネスの発展とともに複雑化していく様子を表しています。
また、この制約はweb注文フォームだけでなく、直接販売によるposレジでも、手書き伝票でも同じルールが必要になることでしょう。ビジネスルール（≒ロジック）がインターフェイスに依存しないことがわかります。分離の3~4の差分でクラスに修正が入らないのは、この依存状態をコードでしっかりと表現できているからです。
| 施策No. | 施策の概要 | 非分離コードの影響範囲 | 分離コードの影響範囲 |
|---|---|---|---|
| 2 | ビジネスの変更 | 全ファイル | 全ファイル（主にクラスファイル） |
| 3 | ビジネスの変更 | 全ファイル | 全ファイル（主にクラスファイル） |
| 4 | UIの改善 | 全ファイル | コンポーネントファイル |
ビジネスロジックの分離がUI改善のしやすさに貢献している事もわかりますね。
さらに発展して、、
reactが突然誰からも使われなくなり、メンテされなくなった未来に来ました。
ピザ屋さんもｗｅｂ注文フォームを提供し続けるため、reactからvueへ刷新することを決意しました。
するとどうでしょうか？
非分離コードはフルスクラッチが必要になり、分離コードではクラスが再利用できるのでコンポーネントだけを書き換えれば良さそうです。
ビジネスロジックの分離によってUI刷新に強いサービスになっていたのです。やったー♪
まとめ
- ビジネスルール（≒ロジック）がビジネスの発展とともに複雑になっていく例を紹介
- ビジネスロジックをUIから分離することでUI改善がしやすくなる（影響範囲を小さくできる）
- 設定上限値のような単純なものでも油断できない
FAQ
Q. 上限数の他にUIに入りやすいビジネスロジックはあるか？
A. ビジネスルールにもよるが、次のようなものはありがち
- 肉をトッピングする場合は相性が悪いので豆腐のトッピングはお断りしている（選択可能項目）
- ミックスピザの場合はほげほげ（ビジネスルールに基づく分岐）