前回
問題編はこっち。
前回のコードの問題点
全て サーブレット にべた書きしていた。
つまり、プラットフォームに依存 するコードを書いていたため、移行がめんどくさかった。
コード量が増えるとよりめんどくさそう。かつ、追えなくなりそう。
分離に着目してみる
分離すると何がいいのか？
私は 変更容易性 の向上にあると思う。
前回のコードではサーブレットクラスにすべての処理を書いていた。
サーブレットの役割はいわゆるコントローラであり、その業務において やりたいこと または、 実現するべきこと を記述するべきではない。
私は主に「 二つ 」の場面で分離している。
- 責任が違うパッケージ
- 型と実装
この二つ。順に解説するよ。
責任が違うものをパッケージとして分離してみる
AIとのチャットアプリケーションの流れはこの通り。
- ブラウザからチャットを送信
- 敬語を使わないで！というルールの作成
- OpenAiAPIにリクエストを送信
- レスポンスの表示
上記の順に考えていこう。
とりあえず、やりたいことなのかやるべきことなのかで分けていくよ。
1. ブラウザからチャットを送信
これは、システム側からすると 何かしら送信された値を取得 する場所になる。
それはブラウザからかもしれないしスマホアプリからかもしれない、discordを使うかもしれない。複数のプラットフォームから送られるかもしれない。
そのプラットフォーム毎に対応した値を取得する処理を記述しているパッケージになる。
つまり、このシステムを成立させるために 仕方なく やっているところだよ。
言い方は気にしないでね。
2.敬語を使わないで！というルールの作成
ここで注目するべきなのは ルールの作成 という言葉。
このルールはどんなプラットフォームから送られてきても 実現したいことは変わらない よね。
このシステムで やりたいこと はただ一つ、敬語を使わないAIとおしゃべり。それだけ。
これは周りの環境に左右されない一番重要なルールになる。
AIとおしゃべりしたいというやりたいことを書いている。
つまり、ここがなくなったら ほかのパッケージが存在している意味がなくなる よ。
3. OpenAiAPIにリクエストを送信
OpenAiAPIにリクエストを送ってレスポンスを取得する…？
じゃあ、やりたいこと はここじゃないの？
実は違うんですよね。
確かに、実際にメッセージを解析してレスポンスを作成しているのはOpenAiさんなんだけど、このシステムが担っているのはリクエストを送る/レスポンスを受け取るのみ。
つまり、OpenAiさんに返信を作ってもらうために 仕方なく やっている処理になるよ。
4. レスポンスの表示
これもAIとおしゃべりするための処理じゃないから 仕方なく やっているところだよ。
こんな感じでやりたいこととやるべきことの分離ができました。
次はこれを具体的なパッケージ、 レイヤ に分割していくよ。
具体的なパッケージ分割
1. プレゼンテーション層
ユーザーのコマンドを解釈する、またはユーザーに情報を表示する責務を負うよ。
つまり、 1. ブラウザからチャットを送信(送信された値を取得) と 4. レスポンスの表示 はこのパッケージに入る。
2. アプリケーション層
ビジネスルールや知識を含まず、やるべき作業を調整する薄い層だよ。
上の手順には書いていない 入力の理解 や ドメイン層やインフラ層に処理を指示する などを行う。
3. ドメイン層
業務の中核 を担うよ。
プロンプトの作成や、型と実装の分離のためのインターフェイス定義なども行う。
4. インフラストラクチャ層
主に アプリケーション層から依頼される処理 を書くところだよ。
DBへの格納やメールの送信など、業務の達成に付随するやるべきことを担う層。
今回だとAPIへの接続やリクエストの送信、レスポンスの取得などを請け負う。
次回
型と実装に着目して分離を行っていくよ。
次回はこっち。