Dressca管理アプリを作成する

[KentaHizume]

概要

Dresscaのto C向けアプリ（Consumer）に加えて、Dresscaの管理アプリ（Admin）を作成する。
バックエンド側については新規に開発するが、
フロントエンド側については、OpenAPI定義の出力を合わせることで、Maiaで動作確認済みのコードをMarisに移植する。
Maris側のissueは下記。

• Dressca管理アプリを作成する maris#1453

詳細 / 機能詳細

バックエンドの機能およびCI/CDに関して記載する。

機能

カタログ管理

• カタログアイテムの一覧を表示できる。
• カタログアイテムを追加できる。
• カタログアイテムを更新できる。
• カタログアイテムを削除できる。

楽観同時実行制御

• CatalogItemsテーブルのRowVersionカラムを用いて、更新の楽観同時実行制御を実現できる。
  • カタログアイテムの更新機能に関連

認証・認可

• ログイン中のユーザーのユーザ名とロールを取得できる。
• ロールが管理者でないユーザーはカタログ管理機能を利用することができない。
• 開発環境では、実際の認証を不要にできる。

CI/CD

• ConsumerとAdminを別々にビルドおよび実行することができる。
• AdminのバックエンドのCIパイプラインが実行できる。
• AdminのフロントエンドのCIパイプラインが実行できる。
• 既存のConsumerのフロントエンド、バックエンドのパイプラインが実行できる。
• openapi-generatorのバージョンチェックワークフローの対象にAdminを含める。

ドキュメント

• 必要に応じて、ガイド>Java編を更新

https://maia.alesinfiny.org/guidebooks/how-to-develop/java/

要調査・検証

Maris側で.NET系の機能で実現しているものに関しては、Javaでの実現方法の調査、検討が必要。

• Consumer/Adminにプロジェクトを分割する（Marisではソリューションフィルター）
• 開発環境で認証を不要にする（Marisでは.NET の標準のフレームワークを利用）
• Controller、ApplicationServiceでの認可処理（Marisでは.NET の標準のフレームワークを利用）
• 楽観同時実行制御の実現（MarisではSQL Serverと [Timestamp]属性）

その他

• MaiaとMarisでOpenAPI定義が（できるだけ）一致すること。
  一致すれば、フロントエンドのコードを共通化しても問題なく動作する。

完了条件

• Adminアプリの上記の機能が問題なく動作すること。
• 既存のConsumerアプリが問題なく動作すること。
• CIが問題なく動作すること。
• 移植したフロントエンドのコードが問題なく動作すること。

[KentaHizume]

全体像

バックエンド

フロントエンド

[KentaHizume]

下記のissueについてて、Adminにも反映する必要がある

• アプリケーションアーキテクチャ概要編にメッセージ管理方針を追記する #89

[kenjiyoshid-a]

PreAuthorizeの引数として利用する、hasRoleとhasAuthorityの違いについて

hasRoleの動作

• ユーザにアクセス権限が付与されていない場合　403
• ユーザがそもそも認証されていない場合　403

hsaAuthorityの動作

• ユーザにアクセス権限が付与されていない場合　403
• ユーザがそもそも認証されていない場合　403

結論

使用する際にはそれぞれhasRole("ADMIN")、hasAuthority("ROLE_ADMIN")と表現する。
今回動作を試したところ、検出される例外に違いは見られなかった。
そのため利用時の違いとしては、hasRoleの方は引数にROLE_がプレフィックスされるというだけっぽい。

[kenjiyoshid-a]

@Nullableをフィールドにつけると依存関係に関する警告が出る。

一部のパッケージで利用する@Autowiredを付与したフィールドに@Nullableを付与してビルドすると、下記の警告が出る。

警告: 不明な列挙型定数ですWhen.MAYBE
理由: javax.annotation.meta.Whenのクラス・ファイルが見つかりません

この警告の原因はmetaパッケージの依存関係不足に由来するため、@NullableはJSR-305というアノテーション群の依存関係を追加すれば解決する。

Spring frameworkのリポジトリには2022年にこのNullアノテーションの依存関係に関するissueが立ち上がっており、spring 7ではspringのNullアノテーションは非推奨になるとのことだった。

今後利用が推奨される関連するプロジェクトであるJSpecifyのver1.0.0は2024年8月にリリースされた。

先に示したissueによれば、JSpecifyの安定性が確認され次第依存関係を変更するとのことなので、今時点では@Nullableではなく他の方法でnull許容を実装する。

[kenjiyoshid-a]

MyBatis Generator で生成したプログラムを楽観ロック対応する。

問題

　カタログアイテムの更新処理を楽観ロック対応させるために編集したクエリが、 DB の構造を変え MyBatis Generator でプログラムの再生成の度に消えてしまう事象が起きている。この事象に対して、 MyBatis Generator で生成したプログラムを正規表現で検索して置き換えを行うツールを作成するという方針も出たが、検索対象が複数行に及ぶため現実的でなかった。

方針

　これまでバージョン管理カラムに対して更新されるたびに整数型のデータをインクリメントしていたものをやめ、現在時刻に変更する。これにより、楽観ロック用のクエリは単行になり正規表現で検索可能になり、 MyBatis Generator で生成したプログラムを変換するプログラムも作成しやすくなる。 現在時刻に変更したとしても、更新処理内で set する操作を行うことには変わりないので、複数行の検索である。
　正規表現以外の有効な置換方法が見当たらなかったので、今回はなるべくメンテナンスしやすいよう、自動生成されたプログラムに対してメソッドごとに正規表現を作成するものとする。なお、追加したタスクは MyBatis Generator によってプログラムの自動生成が行われた際に自動実行されるよう修正を行う。（#1509 ）

※単純にバージョン管理カラムを TIMESTAMP 型に変更すると、 Java に変換された際に、 Date 型になって日単位での楽観ロックしかできなくなってしまう。そこで myBatisGeneratorConfig.xml に対して、 JavaTypeResolver の設定を加える（参考）。これにより、 TIMESTAMP 型が Date 型ではなく LocalDateTime 型に変換され、より細かい単位での楽観ロックを実現できる。

[KentaHizume]

紐づくPRの一つがマージされたことで自動クローズされてしまったのでリオープンします。