-
Notifications
You must be signed in to change notification settings - Fork 3
Architecture
knoQのコード設計について示す。
knoQはDDDライクのレイヤードアーキテクチャを採用しており、コアとなる層は以下の4つであり、上から下に行き、下から上に行くようなフローで実行される。knoQでは層はディレクトリ（パッケージ）名になっている。
- presentation
- domain
- usecase
- infra
まず一つ一つを説明していき、次にこれらの繋がりを見る。
presentationは外とのやり取りを行うためのコードが記述されている。この層はモノによってはinterface（インターフェイス）層とも呼ばれることがあるが、言語機能のinterfaceと紛らわしいため、presentationとしている。
ここでの外とは、ユーザー側をイメージしている。knoQは基本的にデータをjson形式で返すが、イベントはics形式で返す場合や、webhookで送信する場合はユーザーフレンドリーなmarkdown形式に変換することがある。この手の処理を記述しているのがこのpresentation層である。
それぞれの概念（イベントやグループ）などの概念を定める。理想はコードベースで定めることだが、コメントで記述することも許容する。
例として、イベントを扱う。domainには、Eventという型があり、この型はknoQで扱うイベントの全情報を持つ。EventRepositoryはインターフェイスでCreateEventなどイベントの操作を記述している。この時の引数や返値はdomainで定義されているものである。
ドメインは以上のような性質を持つため、他のいかなる層にも依存しない。
EventRepositoryなどの概念の操作を実装する。現状この層はどのユーザーが操作しているかという情報を持ち、domainの定義に従い制約が実行される。
この層が具体的にやっていることは、infra層の関数を適切に呼び出すということである。現状infra層の関数は抽象化されておらず、この層は具体的なinfraを知っているという前提がある。（抽象化が上手くできなかった）
infraにも様々な速度のものがあり、例えばネットワークを介するものはメモリにあるものに比べて圧倒的に遅い。この差異を吸収するのもこの層の役目である。
usecaseは唯一domainで抽象化されており、knoQのtraP とOSSのバージョンの差異はここで扱う。
infrastructureの略で主にはDBなどへのデータアクセスを行う。正確に言うとknoQを支える基盤となるサービスへの実装を行う。
knoQはDBはもちろんtraPバージョンならtraQ、OSSバージョンならgoogleに対して何らかのアクセスを行う必要がある。特にtraQに対するアクセスは現状数多く存在し、レスポンスの低下が懸念される影響でメモリに結果をキャッシュしたいという欲求がある。
この層はこれらのinfraへのアクセスを実装する場所である。抽象化もされていないため、自由に実装できるがusecaseで頑張る必要がある。
WIP