整理: Setting をモジュール内に限局

[tarepan]

内容

概要: Setting をモジュール内に限局してリファクタリング

Setting はエンジンの設定（CORS 設定と origin 設定）をもつ BaseModel である。
router でも利用されており一見すると API モデルに見えるが、実際には内部向け構造体である。router ではコンテナ的に値を出し入れする役割を果たしているに過ぎず、BaseModel 由来の機能は YAML ファイル I/O 用のダンプ・バリデーションで使われている。
ゆえに API では CORS 設定と origin 設定を直接扱って問題ない。そして setting_manager モジュール内でのみ Setting 構造体を利用し影響範囲を適切に限局させるべきである。

このような背景から、Setting をモジュール内に限局するリファクタリングを提案します。

関連 Issue

無し

[Hiroshiba]

これはちょっと避けたいですね･･･。
どれがどれかわからず、フラグが２つ追加された時点でわからなくなり、またSetting構造体に戻ると思います。

内部型であってもrouterに露出するのは問題ないはずです。
例えばデータ変換のときとかは必ず渡さないとなので。
Settingをやり取りする形のがメンテナンス性高そうに思いました！

BaseModelじゃなくても良さそうには思います。

[tarepan]

またSetting構造体に戻る ... Settingをやり取りする形のがメンテナンス性高そうに思いました

👍️
妥当な指摘です。

本 PR の懸念点である 一見すると API モデルに見える は #1405 に基づく dataclass 化によって緩和できそうな見通しです。
よって本 PR はデメリットが勝ると判断し close とします。
なお、dataclass 化は別 PR にて着手する予定です。