
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
リンクをコピー
記事をブックマーク
大嶋勇樹氏:こうやって話してくると、具体的に「じゃあコードをどういうふうに書くの?」「どういうクラスで書くの?」ということを疑問に思うかもしれません。派生形やちょっと違う例もいろいろありますが、典型的な例を1個書いています。
(スライドを示して)これが3層アーキテクチャとMVC(Model、View、Controller)ともいえる典型例です。クラス名のつけ方はいろいろあります。これはどういう構造になっているかというと、まずControllerが入力を受けつけます。入力というのは、通信みたいなものですね。Webアプリであればリクエストを受けつけます。
そしてControllerは、ビジネスロジック層にあるServiceを呼び出します。このServiceはデータベースにアクセスする用のクラス、ここではGatewayと書いています。Table Data Gatewayというパターンで実装した場合、“なんとかGateway”と名前をつけたり、Javaだと“なんとかDAO”みたいな名前をつけたりすることもよくあります。そういうデータベースにアクセスする用のクラスの中にSQLが書いてあるようなイメージを持ってもらえば大丈夫です。
そのサービスはデータベースにアクセスする用のクラスからデータベースと一致するような、例えば“なんとかRecord”やPlayer Recordなどのデータの入れ物を受け取って、ゴニュゴニョゴニョと処理をして、なにか戻り値の型、“なんとかOutput”や“なんとかDTO”と言ったりすることもありますが、それを返して、Viewはそれをそのまま使うか、変換してからかして使います。
こういうのが典型的な3層アーキテクチャです。単語としては“なんとかService”。Player Serviceの代わりにPlayer Logicという名前をつけたり、データベースのレコード、テーブルのレコードと一致するようなクラスを“なんとかEntity”みたいな名前をつけたりすることもあります。
また、データを入れる入れ物クラス。ただデータを入れて返すだけのためのクラスのことを“なんとかDTO”と呼ぶこともあります。ちなみにここで、Entityと出てきていますが、このEntityというのは、データベースのRecordと対応するクラスにそういう名前をつけることもあるし、ぜんぜん違う意味でアプリケーション設計の中でEntityという言葉を使うこともあって、すごくややこしいです。
(本セッションの)この後、こういう箇所ではRecordみたいな言葉を使っていければと思っています。
ここで1つ、質問をもらったので回答しようと思います。質問はZoomのQ&Aの欄をクリックしてもらえれば、ほかの方の質問も見られるようになっています。バージョンによって見えない方もいるようなので読みます。
「HTMLを返す場合、プレゼンテーション層がフロントエンドに該当するのかよくわかりません。HTMLをサーバー側で生成して返すのであれば、それはサーバーサイドの動きではないのですか?」ということです。
それはそうですね。(スライドを示して)ただ、HTMLはブラウザ上でも処理されるものなので、フロントエンドといってもおかしくないぐらいのニュアンスです。
サーバーサイドでHTMLを生成して、ブラウザ上ではそのHTMLを解析していろいろ処理しているわけなので、フロントエンドをサーバーサイドで生成しているみたいな言い方はできなくもないかなと思っているぐらいですね。
ここの用語の使い方に、私はすごくこだわっているかと言うと……。ういう言い方をする人もいるとは思います。質問いただいた方の理解自体はけっこう合っている気はしています。私ともズレていないと思います。
大丈夫そうですね。(質問者の方から)「ありがとうございます」と(コメントを)いただきました。質問は気軽にしてもらえれば。どんどん回答します。ありがとうございます。
ということで、3層アーキテクチャの典型例みたいなものを見てきました。(スライドを示して)これがよくある例ですが、この中でなにが一番謎かというと、たぶんビジネスロジック(層)というものだと思います。
ControllerやServiceなど、データアクセス用のクラスにSQLなりO/Rマッパーを使った処理なりを書くのはなんとなくイメージがつきやすいし、Controllerがいったん受けつけている(という)ところはわかる気がします。
「じゃあ、このServiceはなにを書くところなんですか?」ということは私も最初はよくわからなかったし、「ビジネスロジックを書くところです」と言われても「なにを言っているんですか」という感じだったので、そこを深掘りしていければと思います。
ということで、ここから「ビジネスロジックとは」という話に入っていきます。
(スライドを示して)ビジネスロジックとはというところですが、(その前に)もう1回、プレゼンテーション層、ビジネスロジック層、データアクセス層の絵を描いています。
プレゼンテーション層は、アプリケーションの利用者とやりとりするところ。データアクセス層は、データベースやファイルといったデータの保存先とやりとりするところ。それに対してビジネスロジック層は、「システムのコアやシステムの目的の処理をするところ」とよく説明されます。「ビジネスロジック層は、システムのコアを書くところだよ」「システムの目的の処理を書くところだよ」と言われることがあります。
ただ個人的に、(ビジネスロジック層について)わかってくると確かにそう言いたくなる気持ちもわかるのですが、最初にこれを言われて理解するのは、けっこう難しいんじゃないかなと感じています。
“システムのコア”と言われても、 「それはビジネスロジックの言い換えにはあまりなっていないんじゃないか」みたいなことを感じたり、“システムの目的を処理するところ”と言われても、「例えばどういうことなんだ」という疑問がどうしても浮かぶと思います。
まずは「プレゼンテーションでもデータアクセスでもないところがビジネスロジック」と考えると、とっかかりとしてはすごくいいと私は思っています。
けっこう慣れてくると「まずビジネスロジックから考えるべき」みたいなところ(わかるようになります)。(ビジネスロジックは)コアと書かれるように、すごく重要なところなので、プレゼンテーションやデータアクセスではなく、ビジネスロジック中心に考えるべきだよねという話もあるし、私もそう思います。
ただ最初は、そうは言われてもなにがビジネスロジックなのかわからないと思うので、「プレゼンテーションでもデータアクセスでもないのがビジネスロジック」と考えると、第一歩としてはいいんじゃないかなと思っています。
(スライドを示して)具体例の話になりますが、「リバーシ」(というゲーム)を考えてみましょう。Webアプリでもモバイルアプリでもいいのですが、「リバーシ」を作ってみようという時に、盤面に石を打つようなことをすると思うんですね。
盤面に石を打つ時の処理の流れは、プレーヤーが石をどこに打つかをまず受けつけて、そしてデータアクセス層から盤面の状態を取ってきて、盤面に置けるかをチェックして、石をそこに置いて、挟まったやつをひっくり返して、盤面の状態をデータアクセス層を使って保存して、画面に新しい状態の盤面を表示するというのが一例です。こうじゃない可能性もありますが、例えばこういう流れになると思います。
このうち最初と最後については、ユーザーとやりとりしていますね。アプリケーションの利用者とやりとりするところ、つまりプレゼンテーション層ですね。入力を受けつけたり、画面を表示するのはプレゼンテーション層の役割です。
そして、データアクセス層のメソッドを呼び出すイメージですね。データベースにアクセスするメソッドを呼び出して、盤面の状態を取ってきて、置けるかチェックして、石を置いてひっくり返して、さらにまたデータアクセス層を使って保存します。このあたりがビジネスロジックです。「リバーシ」で石を打つ時の処理の例でいえばこんな流れになります。
こんなふうに、ビジネスロジックには利用者とやりとりする方法、例えば入力をどうやっているのか、それがAPIみたいな方式なのか、Webアプリで画面クリックしたのかみたいなところは関係ありません。画面の表示の仕方もこの間には関係ないですね。
保存先のデータベースの種類も、データアクセス層の先に隠蔽されていれば、メソッドとして呼び出すだけであれば、ビジネスロジックの中には関係ないわけです。このあたりがまさにビジネスロジックの例であって、ビジネスロジック層に書くべきコードの例です。
これだけだと、例が少ないと思うので、もういくつか見ていこうと思います。
(スライドを示して)これは「ビジネスロジックかどうか」みたいなやつです。これはすごくよくある例だと思いますが、見た目を整えるために、日付時刻の形式を「何年何月何日」みたいな形式に変換することはよくあると思います。
これがビジネスロジックかというと、見た目を整えるための日付時刻の形式変換はUIを整えるための処理、(つまり)プレゼンテーション層の役割であって、ビジネスロジックではないと言われる、判断されることが多いです。
ここが難しいところでもあるのですが、もしも日付時刻形式変換アプリケーションみたいなものを作ったとすると、その場合、日付時刻形式変換はアプリケーションの中のコアみたいなものですね。
“コア”という結局わかりにくい言葉を使っていますが、そのアプリケーションが本当にやりたい処理は日付時刻の形式変換であって、そういう時は、この処理はビジネスロジックであると言えると思います。
こんなふうに、同じ処理でもアプリケーションの性質次第で、ビジネスロジックかどうかが変わることがあります。
特に日付時刻の形式変換は、だいたいの場合、プレゼンテーション層の役割と言われることが多いと思います。しかし、もし日付時刻形式変換がメインのアプリケーションだったらそれはビジネスロジックというか、「そのアプリケーションの一番重要なロジックだよね」となるということですね。
1個質問をもらったので回答しようと思います。「石を置いたりひっくり返すステップもビジネスロジックと呼ばれるのでしょうか?」ということです。
そうですね。石を置いたりひっくり返す処理も、私はビジネスロジックだと思います。この「石をひっくり返す」が何を指しているかですが、画面上でひっくり返すアニメーションを指しているのであれば、それはビジネスロジックではないですね。
アニメーションみたいなものは表示上の話で。(ただ)それもアプリケーションの種類次第なところはあります。例えば毎ターン、盤面の状態をデータベースに保存するようなことを想像してもらいたいのですが、Webアプリで石を置いたりひっくり返す時は、たぶん内部に2次元配列みたいなものを持っていて、その配列の値を変えたりすると思うんですね。
「ここからここはひっくり返りそうだ」みたいなチェックをしてひっくり返すと思うのですが、そういうチェックしている処理はビジネスロジックですね。
一方、ここでは新しい盤面を表示するという中で表示上のひっくり返りが動くイメージでしたが、それがビジネスロジックかというとそうではないですね。質問ありがとうございます。確かにこの例だとわかりにくかったかもしれないですね。ありがとうございます。
(次回に続く)
関連タグ:
“1つの独立して動く要素”の内部を整理し直す 「改めて整理するアプリケーション設計の基本」で伝えたいこと
アプリケーションアーキテクチャ理解に必要な“3層構造” プレゼンテーション層・ビジネスロジック層・データアクセス層それぞれの役割
3層アーキテクチャで最も謎な「ビジネスロジック層」 “システムのコア”をゲーム「リバーシ」で解説
「ビジネスロジックの処理は2つに分類すると整理しやすい」 4つの例から考える、プレゼンテーション層・データアクセス層の見分け方
ビジネスロジック層内部の2つの実装パターンを比較 選択時に考えたい、アプリケーション設計の観点
「クラスごとの役割を明確化すること」がポイント アプリケーション設計におけるドメインロジックの分離法
重要なのは「基本を押さえ、適したものを採用すること」 “本来の役割”を押さえたアプリケーション設計
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
PR | 2025.02.07
プロジェクトマネージャーは「無理ゲーを攻略するプレイヤー」 仕事を任せられない管理職のためのマネジメントの秘訣
2025.02.04
日本企業にありがちな「生産性の低さ」の原因 メーカーの「ちょっとした改善」で勝負が決まる仕組みの落とし穴
2025.02.05
「納得しないと動けない部下」を変える3つのステップとは マネージャーの悩みを解消する会話のテクニック
2025.02.06
落合陽一氏や松尾豊氏の研究は社会に届いているか? ひろゆき氏が語るアカデミアの課題と展望
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.05
エンジニアとして成功するための秘訣とは? ひろゆき氏が語る、自由な働き方を叶えるアプリ開発とキャリア戦略
2025.02.03
手帳に書くだけで心が整うメンタルケアのコツ イライラ、モヤモヤ、落ち込んだ時の手帳の使い方
2025.02.03
「昔は富豪的プログラミングなんてできなかった」 21歳で「2ちゃんねる」を生んだひろゆき氏が語る開発の裏側
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
PR | 2025.02.07
プロジェクトマネージャーは「無理ゲーを攻略するプレイヤー」 仕事を任せられない管理職のためのマネジメントの秘訣
2025.02.04
日本企業にありがちな「生産性の低さ」の原因 メーカーの「ちょっとした改善」で勝負が決まる仕組みの落とし穴
2025.02.05
「納得しないと動けない部下」を変える3つのステップとは マネージャーの悩みを解消する会話のテクニック
2025.02.06
落合陽一氏や松尾豊氏の研究は社会に届いているか? ひろゆき氏が語るアカデミアの課題と展望
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.05
エンジニアとして成功するための秘訣とは? ひろゆき氏が語る、自由な働き方を叶えるアプリ開発とキャリア戦略
2025.02.03
手帳に書くだけで心が整うメンタルケアのコツ イライラ、モヤモヤ、落ち込んだ時の手帳の使い方
2025.02.03
「昔は富豪的プログラミングなんてできなかった」 21歳で「2ちゃんねる」を生んだひろゆき氏が語る開発の裏側
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10
片付けパパ対談【特別編】 整理術×行動術×メモ術で、仕事も人生も自在にデザイン!
2024.12.16 - 2024.12.16
日本を変える 中小企業リーダーズサミット2025
2025.01.30 - 2025.02.12