どこの層まで Thor であることを意識させるかというのはポイントになりそうな気がします。 database は Thor 以外からはけして呼ばれないでしょうか？ たとえば、Web インターフェイスをかぶせた場合。bot を呼出し元として使い始めた場合。 実際にそれらを作り始めて不都合が出てから変えてもいいのですが、今の時点で
+--------------+ +-----------+
| dispatcher | | view |
+--------------+ +-----------+
+----------------------------+
| logic |
+----------------------------+
+----------------------------+
| database |
+----------------------------+
というレイヤードアーキテクチャを意識しておくとコードの役割をシンプルにできるかもしれません。
順番としては CLI の起動から、dispatcher へ入って logic が database を制御し、view として結果を出力します。 この構成を Thor で当てはめると、たとえば
- dispatcher: Thor クラスを継承した CLI クラス
- logic: アプリケーション固有のライブラリ群
- database: Database クラス
- view: Thor クラスを継承した CLI クラス
へマッピングすることができます。
こう考えると、Thor 的な要素を感じさせるのを dispatcher, view のレイヤーにとどめておくと、logic や database は他への適用が容易な設計にすることができます。
レイヤードアーキテクチャは
- 上の層は下の層のことを知っていることを許されるが、下の層は自分を呼出す層のことは知らない前提に立つ
- 直接呼出しをできるのは一つ下の層までで層を飛び越えて呼出しをすることは許さない
というルールを課すことでアーキテクチャを疎結合に保つ設計のパターンの一つです (だいぶ説明端折ってるので興味があったら調べてみてください)。