システムロジックとビジネスロジックを分ける

たまには開発関係の事書きます。
システムロジックとビジネスロジックにプログラムを分け方です。

【どうして分ける必要があるのか?】

それは私の大好きな保守性wを高めるためです。
バグがあったときにトラブルシュートしやすい、カスタマイズの時にやりやすです。
また、自分以外の人がメンテする時に、コードの説明が減ります。
一応、言っておくと、
・可読性悪いがすごいコードを書いた!
・いちいちコードの説明しなきゃいけないなんて、あほプログラマーめ!
と思っているエンジニアの方、残念です。

私は経営者の立場でもありますので、このようなプログラマーは天才でも不要の可能性がありますが、その理由は「時間コスト」です。
これはビジネス的には機会損失になります。無意味な残業が生まれる可能性があります。
むしろ、
・可読性高く
・説明不要な
・しっかり動く素晴らしいプログラム
をご用意頂きたいところです。
エンジニアのためにビジネスがあるのではなく、ビジネスのためにエンジニアがいる事を忘れてはなりません。

本題に戻ります。
「商品を購入した時に、ご購入ありがとうございました画面を出す」という処理を考えてみます。

【どんな処理があるか?】

「商品を購入した時に、ご購入ありがとうございました画面を出す」という処理を、少しだけ細分化すると
・購入した商品を、DBへ登録
・入力された顧客情報を、DBへ登録
・購入者とショップに、メール送信
・ご購入ありがとうございました画面を表示

【ビジネスロジックとは?】

正確ではないですが、簡単に言うと「業務フロー」です。
ショッピングカートで例えると、
・商品をカートに入れる
・商品購入をする
・カード決済をする
・お客様にご注文メールを送る
・ご注文時に在庫を減らす
などです。
これらはどのECサイトでも持ち合わせなければならない機能です。
その点においては、抽象化しやすい、オブジェクト化しやすい箇所ではありますが、私はそうしない方が良いと思います。
なぜなら、ビジネスロジックだからです。
ビジネスロジックは、その会社や業務によって改造される可能性が高く、そういったものを抽象化すると、あとで取り回しがきつくなり保守性が落ちます。

エンジニアはとかく、抽象化したがりますし、それが良いと思われがちです。
しかしながら、ビジネスサイドは真逆でより変化をしてゆく方向性があります。
例えば、ECサイトは差別化が必須になります。
そうなると、購入の仕方や運用方法も独自性を持たざる得なくなり、エンジニアの気の利かせた抽象化は足枷にしかなりません。

【システムロジックとは?】

極端な事を言うと、どんなシステムでも利用するようなプログラムコードです。
実際には、完全に汎用できない場合もあります。逆に完全に汎用化できるものは基底クラスとして利用できると思います。

さて、上記のショッピングカートで例えると、まず具体的には以下のような処理が必要になります。
・購入商品の情報をDBから取り出す
・購入商品の情報をDBに入れる
・お客様情報をDBに入れる
・購入内容などをメールする
・それぞれの画面を表示する

これらから導き出されるシステムロジックは以下です。
・DBに入れる
・メールを送る
・DBからデータを取る
・動的なHTMLを表示する

この箇所が抽象化できる場所です。ここをどのくらい抽象化するかは人によるでしょう。個人的には多くて3階層くらいにとどめた方が良いと思います。
正確ではありませんが、例えとして、
クラス⇔継承⇔継承 など。

私は、1つですませています。
単に「DBとやりとりするクラス」「メールを送るクラス」「動的なHTMLを表示する」です。

こんな感じです。
まずは簡単なお問合せフォームで試してはいかがでしょうか?

返信を残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA