nitoliです。ずいぶん活動報告が止まっていましたね。
活動報告は、ブログを書く人を決めるbotに担当を決めてもらっていたので、botを止めて以来スッカリ忘れるという状況になっていました。最近RMSプロジェクトは曜日を問わずほぼ日で開発をしているので、思い出し次第書くようにしないとなりませんね。

件のRMSはいわゆるCRUDアプリなのですが、複雑怪奇、老眼でなくとも目をしょぼつかせる、混濁を極めると請け合いの弊学の履修システムを管理するという要件がために、見た目よりずっと工数の多いプロジェクトになりました。
すでにコミット数1,000を超えるプロジェクトになっており、それを支えるべく、効率的に、保守しやすく、開発しやすく作るために、様々な工夫が盛り込まれています。

今日はそんな開発の工夫を書いていこうかなと。

DDDについて

バックエンドは、DDD(Domain Driven Design, ドメイン駆動開発)、中でもオニオンアーキテクチャと呼ばれるものに近いアーキテクチャを採り入れています。

この図は現状のものではないです。現在、APIの層はHandlerとは呼ばれておらず、Controller層はHandler層と読み替えてください。

フロントエンドとの通信部分を記述するHandler層、中間レイヤーとして主にバリデーションを行うModule層、DBなどとやりとりするRepository層に分かれています。各層はModelと呼ばれる構造体をやりとりします。疎な結合なので、例えばDBをCassandraに載せ替えるとしたら、該当するRepositoryだけを差し替えることで、他の部分にコテ入れなく実装を取り替えることができます。

Strategy Patternが多段で組まれていて、保守性を高めようという気概を感じる設計ですね。

テストについて

RMSの開発では、テストもやるべきこととして捉えています。
バグのないプログラムならさておき、テストの機会は何度も訪れます。その何度も行うテストを手動でやるのは正気ではないです。
ここが一度書けば自動化できるというのがテストのうまみですね。

ただ、よくある言説として、テストは面倒なんですね。テストを書くのが面倒だし、テストの環境を用意するのが面倒。

採用している言語であるgoがうまいな、と思う部分は、テストがはじめから組み込まれていることですね。
「hoge_test.go」のようなファイルを用意してテスト用の関数を書けば、あとはgo側で提供されるコマンドを叩けばテストできます。
敷居がとても低い。

テストもそうなのですが、goはさっくり書けてしっかり動くものができるのがいいですね。

おわりに

以上、バックエンドの開発の工夫でした。
こうした工夫は随分前からやってたよな？と思ったのですが、誰も書いてなかったので筆をとりました。

そんな工夫をしている開発の進行度ですが、今はある程度Module、Repositoryを書き終わり、そろそろフロントと結合してみようという兆しが見えてきました。
そろそろ文字ではなく画像で成果が見られると思います。

それではまた。