システム開発は設計が命！たっきん(Twitter)です！
ROS2を使ったOANDA-APIのインターフェース周りの作成もある程度完成してきました。
今後はさらに上位のロジックの作成を始めていくことになるのですが、何の方針も決めずに作りこんでいくと中身がぐちゃぐちゃのアーキテクチャになりかねません。
ただでさえ、頻繁なロジック変更や機能拡張していくことが予想されるので、このタイミングでシステムのアーキテクチャについて少し考えていきたいと思います。
せっかくROSという優れたミドルウェアを使っていることですし、ROSの良さを潰さないためにも最適なアーキテクチャ設計をしていきたいと思います。
余談ですが、僕は仕事でもソフトウェア設計をそこそこやっているので、この分野は得意なんですよね♪
設計は苦手って人は結構多いんですけど、僕からしたらパズルを解いているような感覚でむしろ楽しいくらいです！
設計方針
まずは方針を決めていきましょう！
上でも言いましたが、今回開発しているシストレは頻繁なロジック変更や機能拡張していくことが予想されることから以下2つの方針にしようと思います。
- モジュールの再利用が可能であること
- 仕様変更、機能拡張に柔軟に対応可能であること
まず１つめのモジュールの再利用性について補足ですが、なんで再利用性が必要なの？って思った方もいると思います。
現状OANDA-APIでシストレ運用を考えていますが、この先もしかしたらOANDA社以外でもAPIを公開するところが増えてきて、しかもOANDA社よりもスプレッド・コストが低いなどの好条件となる可能性もあります。
もしそうなって他社に乗り換えようとした場合、少ない仕様変更規模で容易に載せ替えができるほうが良いですよね！
そのためにも、OANDA API専用にシストレ・アプリケーションを作りこむのではなく、モジュール分割してなるべく汎用性の高いインターフェースに仕上げていきたいと思います。
アーキテクチャ設計
ではさっそくアーキテクチャを考えていきましょう！
ただし、この時点での設計は大雑把でいいです。
がっつり設計したところで作りこんでいくうちにどうせ設計変更が入るので（笑）
専門用語をつかうとスパイラル開発風にやっていこうと思います。
現状、下図のようなアーキテクチャを考えました。
＜シストレ・アーキテクチャ ver.0.1＞
ミドルウェアとしてROSを使用しておりNodeベース開発が基本になることからも、ノードをモジュールとみなして描いてみました。
図中の各パーツの説明は以下のようになってます。
| パーツ | 説明 |
|---|---|
 | ROSパッケージ |
 | ROSノード |
 | ROSのTopic通信 |
 | ROSのService通信 |
今のところ３つのパッケージで構成していこうと思いますが、今後作りこんでいくうちにパッケージが増えていくことも十分あり得るので参考までに。
| パッケージ名 | 用途 |
|---|---|
| system_trade | ・メインのシストレ・アプリを構成するパッケージ ・再利用性を高めるため、下位のパッケージとのインターフェースは極力抽象化 |
| oanda_api | ・OANDA APIを構成するパッケージ ・他社APIに載せ替える場合、このパッケージを丸ごと入れ替えることになる |
| historical | ・履歴やログを残すためのパッケージ |
次は各パッケージ内で実装予定のROSノードの用途についてまとめてみました。
こちらも大雑把に考えたので今後変更になる可能性が高いです。
●oanda_apiパッケージ
| ノード名 | 用途 |
|---|---|
| pricing_streamer | OANDAサーバーからリアルタイム価格の取得するトピック |
| order_service | OANDAサーバーへ注文を発行するサービス |
| candlestick_service | OANDAサーバーからローソク足、オーダーブック情報を取得するサービス |
●system_tradeパッケージ
| ノード名 | 用途 |
|---|---|
| APL_*** | 窓埋め、ゴトー日＆仲値攻略などのアプリを実装 |
| order_manager | 注文の管理 |
| candlestick_manager | ローソク足、オーダーブック情報の管理 |
●historicalパッケージ
| ノード名 | 用途 |
|---|---|
| historical_service | 履歴の読み書き、ログの掃き出し |
注文シーケンス設計
アプリケーションから注文指示が出されるシーケンス図も作成したのでついでに載せておきます。
この図を理解するにはUMLの知識が必要になってきますが、この記事ではUMLの説明はしません。
UMLについて知りたいか方はググるとたくさん情報がでてくるので、そちらで学習してみてください。
この図も大雑把につくったものになるので最終的に変更が入る可能性大です。
現状、注文を出す際には必ず決済注文（OCO注文）も併せて出すルールにしています。
そのルールに基づいてシーケンスを考えた場合、注文シーケンスはおのずと以下の２種類しかないという結論に至りました。
- 成行注文（新規注文）＋ OCO注文（決済注文）
- 指値or逆指値注文（新規注文）＋ OCO注文（決済注文）
■成行注文＋OCO注文 シーケンス図
■指値or逆指値注文＋OCO注文 シーケンス図
さいごに
今回はアーキテクチャ設計についての記事を書いてみました。
人によっては設計図を描かずにコーディングを始める人もいれば、「仕様通りに動けばみんな一緒でしょ？」と言って設計を疎かにする人もいます。
ただそれは必ずしも間違いというわけではありませんし、仕様通りに動くものが作れれば確かに設計図は必要ないのかもしれません。
しかし、その代償として設計をしなかった場合に比べて複雑なロジックになりやすく、設計変更や機能拡張する際にバグを仕込む確率が上るのは間違いありません。
また、複雑なロジックはコードの可読性が低下するので正直面倒くさいです。
僕は面倒なことが嫌いな性格なので、設計段階でなるべくシンプルなロジックを考え、後々になって面倒なことにならないようにすることをポリシーにしています。
さて、ある程度アーキテクチャ設計も固まったことですし、またゴリゴリ作りこみを始めていきたいと思います。
それではまた！
コメント