botterアドカレの記事です。
みんなbotの設計どうやってるんだろー、なんかbotのアーキテクチャの記事って少ないよなー、と思ったのでまずは自分が書いて公開することにしました。
私が見たことある設計周りの記事は、hohetoさんの記事と、同じアドカレ内のとっとり（砂丘）さんの記事があります。ご参考までに。
設計はいくらがんばっても収益には直接結びつかないですが、きちんとした設計は迅速なbot開発や安定稼働などにつながり、収益機会を逃すことが減るはず。
オレオレbot設計の概念図
私のbot設計を書きます。おそらく一般的な設計だと思います。
このbot設計は、基本は1分足以上のロジックを想定していますが、板を見て発注するような高頻度ロジックの稼働実績もあります（1ヶ月で3000円ぐらいの雑魚高頻度botでしたが、、、）。
■実稼働クラス設計
■バックテストクラス設計
- 実稼働はbot稼働プロセスとdata fetchプロセスの2プロセスで動く。
- exchangeクラスとapiクラスで取引所ごとの差異を吸収したり、エラーハンドリングしたりする。
- botのロジック記述は実稼働とバックテストで共通。また、どの取引所なのか、どのペアなのか、実稼働orバックテストをほぼ意識しない。
主なクラス
- bot
- exchange
- backtest_exchange
- data_getter
- data_fetcher
- rest_api
- realtime_api
- parameters
bot
botのロジックを記述するクラス。取引所ごとの差異やエラーハンドリング、バックテストかどうかを意識しなくても良い。
exchange
botのロジックからの発注処理(create_limit_order,cancel_order,...)やデータ取得処理(get_ticker,get_book,get_ohlcv,...)を処理する。取引所ごとの細かい仕様の違いを処理し、botクラスでロジックに集中できるようにする。
細かい違い例：
・最小ロットの差
・pipsの差
・ほとんどの取引所でリニアBTCUSDペアで1枚=1BTCなのに、phemexは1枚=0.001BTCなど
・APIで証拠金取得した時、未確定損益が含まれている値かどうかの違い
backtest_exchange
バックテストのためのexchangeクラス。シミュレーションでexchangeクラスのように振る舞う。
rest_api, realtime_api
取引所のAPIに接続するクラス。取引所ごとにこれを継承したクラスを作り、クラス内で取引所ごとの差異を吸収する。エラーハンドリング、遅延発生時の再接続をこのクラス内で完結。
data_getter, data_fetcher
処理については略。
データベースはsqlite。ちゃんとしたデータベースにするかどうか検討中。
データベースにはローソク足や約定情報のほか、手数料やpipsなどを保存。現状、データ量が増える&過去データ取れないので板情報はない。
parameters
上の概念図には書きませんでしたが、parametersクラスで全クラスのパラメータを管理しています。
たとえば、
params.backtest=True
とすれば各クラスはbacktestモードで動くようになります。
params.pairs=[["binance","btcusdt"]]
とすれば各クラスはbinanceのBTCUSDTを参照するように動きます。
おわり
みなさんもbot設計公開しましょう！