プログラミングのすすめ。PLとBLを明確に分けましょう!

徒然草2.0

PLとはプレゼンテーションロジックのことで、BLとはビジネスロジックのことを指す。

プレゼンテーションロジックとは

表示部分。値入力。編集画面。編集画面上のエラーチェックを行うところ。ユーザーインターフェース層とも呼ばれる。その名の通り、ユーザが向き合う画面部分のロジックを指す。

ビジネスロジックとは

データ処理を行うところ。業務上必要な計算などをおこなすロジックを指す。

PLとBLがごちゃ混ぜになったシステムは失敗だ

※なお今後は、プレゼンテーションロジックをPL、ビジネスロジックをBL、ユーザ―インターフェースをUI、ユーザーエクスペリエンスをUXと表記する。

「PLとBLまぜるな危険!」とは言ってみたものの、これが言葉が本当に正しいか分からないが、プログラミングをしていて、これははっきりと区別しておくべきだと常々思う。

ひどいデータ構造と処理ロジックに出会ったことが何度もある。プログラミングを上手くやるためには、このデータ構造と処理ロジックを、いかにうまく扱うかに掛かっていると言っても間違いない。オブジェクト指向プログラミングやその上位概念とでもいいのかDDD(ドメイン駆動設計)もひいて言えばこのPLとBLの整理手法ではないだろうか。(例えば、オブジェクト指向でなくても名前空間でメソッドや変数の独立性は保てるという人がいるし自分もそう思うところがあるが、名前空間ではPLとBLの分離は考慮されないあくまでコードレベルの独立性を担保するものだ。オブジェクト指向もBLを意識したPLというふうに現実世界のモデリングを意識しなくては中途半端なものになるが…それは今回その点にふれると話がややこしくなるのであえてふれません)

さて、PLとBLが混同された問題は、往々にしてデータ構造と処理ロジックの分別がつけられていないことに通じる。

PL/BL混合問題のとあるシステムとは、具体的に以下のようなものだ。

  • 画面から入力されるAとBのパラメータがある。この値はAかBのいずれかが採用される…採用された変数値が請求金額へ加算される。ソースコード上では、請求金額へ加算される値は、A+Bが加算されている。したがって、採用されない方の変数は、画面へ入力する際に数値0にしておかなければならない。

…とまあ、こんな具合なのだが…これの何が問題か説明できるだろうか?

ロジック的に問題なくつくればOKという回答も間違ってはいない。

正しく動いている業務システムであれば問題ないと言ってもよいのかもしれない。

しかし、AとBのいずれかが採用されるということを、画面に0を入れることで実現していることは、非常に危うい。

AにもBにも値を入れてしまう恐れがあります。つまり、ビジネスロジックの知識がない人が間違いを起こしやすいPLになっているのです。これは問題が起こったら、入力したオペレータの責任にするのでしょうか。

例えばこの場合の解決策としては、AまたはBに値をいれたことを表すフラグ的なものがあって、それはどちらを指すのか明示的に選ばせるようにしたほうがよいでしょう。

フラグというデータカラムが増えることになることを嫌うならば、もう少しデータ分析等を適切に行ったほうがよいでしょう。

ちなみにA+BというBLが、PL部分のロジックを前提に作られていることになります。つまり、PLとBLの区別がつけられていない人物が仕様を決めているのです。

PLとBLの絶妙なバランス

だが、PLとBLを明確に分けるつくりにすると、あるデメリットが生まれがちのため、PLとBLの明確な分離を嫌う人が少なくありません。そのデメリットは、手数が増えて慣れた人が使いづらいということ。

自分が考えた画面は素晴らしいと思っている人(?)ほど、ビジネスロジックとプレゼンテーションロジックを一緒くたにした画面設計をしがちです。

私もUI・UXの設計にはまったく定評がありません(!)が、このPLとBLの混同はシステムとして致命的になりかねないので、PLとBLを無理やりくっつけるような愚には、先んじで気づきます…というか、ビジネスロジックなんて知らない方が、実は客観的にUI・UXを評価できたりするものです。

よく誤解されることですが、必要なのは分別です。

ちなみにPLとBLの分離は、UIの使いづらさにつながりやすいですが、必ずしもUIが使いづらいわけではありません。というか、PLとBLの分離を果たしながら、最高のUI・UXを目指すのが理想の画面設計です。というか、PLとBLを考慮した設計がUI・UX設計の幹部分だとすら思っています。

まとめ

  • PLとBLは明確に分ける意識をしよう
  • PLとBLを意識することのメリット
    • ユーザが使いやすい → システム屋の評価が上がる
    • データ構造を見るだけでビジネスロジックが分かる
    • オペレータは画面を見るだけで動かし方が分かる
    • エンジニアは保守しやすい

結論

PLとBLの意識をしよう!

コメント

タイトルとURLをコピーしました