シンプルなTODOリストアプリ

必要なもの

Docker

docker imageを作成する方法

Dockerfileの内容をもとに、「to-do-app-sample」という名前のイメージを作成する。

docker build -t to-do-app-sample .

実行する方法

docker-compose.ymlの内容をもとに、webを実行する。 8080ポートで公開する。

docker compose run -p 8080:8080 --rm web
or
docker compose up web

auto reloadを有効にする

実行中に、別のターミナルで以下を実行する。

docker compose exec web ./gradlew -t build -x test -i

確認方法

localhost:8080をブラウザで開く。

試したいこと

Dockerで実行環境を作る
IntelliJ IDEA Communityを使って開発する(Dockerの中で開発しようとしなければできる)
Kotlin + ktorを使ってWebアプリとして雑に実装する
ユーザの認証・認可をする
ユーザ追加・削除をする
トランザクションを考えてみる
- ユースケースで整合性のチェックをするが、どう頑張っても失敗するときは失敗するので厳密なトランザクションにはしない。
- 同時実行によるUnique制約などの不整合は、レアケースとみなしてインフラで処理して例外を投げる。（実装漏れは心配になるけど、どこかでテストすればOK）
- 絶対に失敗できないときと、リポジトリをまたぐときだけは、ユースケースでDB由来のトランザクションをはる。（結果整合性を許容できるなら不要かも？）
エラーの通知方法を考えてみる
- 成功か失敗の二択ならOptional
- 失敗の理由を返す必要があればsealded class
- メソッドに値を渡す側の処理が、値のフォーマットのように渡すべきデータを作れるなら例外を投げる、重複チェックが必要といったように値を渡すまでわからない場合は例外を投げずにエラーやnullを返す。
バリデーションをどうするか？
- ドメイン
  - 例外を投げて作業を止める！！
  - ここでの例外発生時は攻撃や実装上の不具合とみなし、この例外は共通の場所で処理する
  - ここでの検査はホワイトボックスにする
- ユースケース
  - バリデーションはドメイン任せ！！
  - ロジックとしての重複チェックといった確認はするが、検査はしない。
- コントローラ
  - リクエストヘッダなどの不正をバリデーションする
- ViewやAPIクライアント
  - 入力の仕様(形式、範囲)に合わせてリクエストする
  - 入力の仕様はドメインによって決まる
  - ここでのチェックに合格しないリクエストはすべて攻撃扱い（責任をクライアントへ丸投げ。。）
SwaggerでRESTのレスポンスを定義する
RESTに対応する
gRPCに対応する
SPAに書き換える
DB周りの実装を差し替えてみる
GraphQLに対応する

t-matsumo/ToDoAppSample

必要なもの

docker imageを作成する方法

実行する方法

auto reloadを有効にする

確認方法

試したいこと