takeda_san’s blog

KotlinとVRを頑張っていく方向。

Spring Boot+Kotlinでコマンドラインバッチをこう作ってます

概要

みなさん、バッチ作ってますか?
私はもりもり作ってます。

そのときの選択肢として、Spring Boot+Kotlinを使うことが多いので基本的なテンプレを改めて作りました。 ついでに、なんでこんな構成なのかみたいなところを書いていきます。

このコマンドラインバッチ用途

最終的には実行可能Jarを生成してコマンドラインから実行可能にするので、JdkなりJava実行環境があれば動きます。
なので、AWS Batchで動かすもよし、自前の環境で動かすも良しです。
扱うデータ量が多かったりトランザクション制御をちゃんとやりたい処理に向いてると思います。

リポジトリ

github.com

パッケージ構成とクラスの考え方

f:id:takeda_san:20210130195551p:plain

エントリーポイント

これは、意図も何もないですね。
エントリーポイントです。

引数を受け取り、このあとに説明するUseCaseをただ実行するだけのクラスです。

UseCase

Service間の調整をするクラス。
以前はServiceのパッケージに混ぜてServiceからServiceを呼び出していたのですが、ちょっと依存関係が同じパッケージ内で発生するのが違和感あったので役割ごとにパッケージを分けました。
結果的に依存関係が整理できてよかったかなと思います。

また、UseCaseという名前にすることで業務シナリオごとにクラスを分けるようになったので、クラスの分け方が少しだけ明確になりました。
多人数で開発をするときにこのUseCaseごとに開発を分担するみたいなのが出来てうれしいかもしれません。

Service

DAOを使いデータを取得し、次に説明するEntityで目的の形式に加工して返却するクラス。
一般的なServiceとあまり変わらないイメージです。

ただし、変換のビジネスロジックはEntity側に持つようにしてServiceには持たないようにします。
これはDDD的な文脈もあるのですが、単にPOJO的なクラスにビジネスロジックを持たせることでテストを書きやすくする意図もあります。

Entity

Entityって書いてありますが、DDD的にはValue Objectです。
ややこし。
データの変換はこのEntityが担います。

DTOとDAO

データにアクセスするIFであるDAOクラスとそれをそのまま格納するDTOクラス。
これも一般的なものと変わらないイメージです。
DTOとEntityの違いですが、ビジネスロジックを持つ、持たないという違いがあります。

コーディング中の動画

今回あらたな挑戦として、作業の模様を配信しておりました。
作業が適度な緊張感で捗るので次回からもやるかもしれない…