（Dressca）Open API 仕様書の更新に追従する

[KentaHizume]

この Pull request で実施したこと

• Consumer、Adminについてopenapi-generatorの自動生成コードを更新し、フロントエンドへの影響箇所を修正しました。

Consumer

• Adminの追加に伴うOpenAPI仕様書への相対パスの変更をコマンドへ反映しました。
• 下記のissueを解決し、catalog.api.mock.tsの実装をMarisと共通化しました。
  • Maia-Maris間でPagedListOfCatalogItemResponseの構造が異なる #1215

Admin

• 下記の変更に伴う OpenAPI 仕様書の更新に追従しました。
  • アイテム削除処理において楽観同時実行制御を行う
    • rowVersion をクエリパラメータで引き渡すように修正しました。
    • 削除処理の実行時に、レスポンスコード 409 を示すカスタムエラー ConflictError をcatchしてハンドリングするように修正しました。
  • ユーザーのロールを複数返却する
    • 参照する型名および、セッションストレージに保持するキー名を修正しました。画面表示については特にこだわらず配列をそのまま表示する仕様としています。
  • Dtoの命名を命名規則に従って修正
    • 参照する型名を修正しました。

この Pull request では実施していないこと

なし

Issues や Discussions 、関連する Web サイトなどへのリンク

上述の通りです。

[1nu1taichi]

@KentaHizume @tsuna-can-se
PagedListOfGetCatalogItemResponse について、こちら の会話からは<HTTPメソッド><モデル名><In/Out>にする方針とあり、GetPagedListOfCatalogItemResponse にするのが適切ではないかと思いました。

[KentaHizume]

@tsuna-can-se @1nu1taichi
ご指摘の通り対応する場合、 Marisの場合は下記のようになるのですが、
Dto.CatalogItems 配下に GetCatalogItemResponse と CatalogItemResponse が2つできると見通しが悪くなる懸念があります。
ただ、GetPagedList<GetCatalogItemResponse>はGetが入れ子になって気持ち悪いですかね…？

（例）
GetPagedListOfCatalogItemResponse にする場合、

• GetPagedList にリネーム（その場合は SystemCommon から Web などに移動？）
• Dto.CatalogItems 配下に GetCatalogItemResponse に加えて CatalogItemResponse を追加

[ProducesResponseType(StatusCodes.Status200OK, Type = typeof(PagedList<GetCatalogItemResponse>))]

[tsuna-can-se]

@KentaHizume
Dtoのクラスはリクエスト・レスポンスに対してひとつずつ作る想定です。
そのクラスのメンバーにPagedListのオブジェクトがいたり、CatalogItemのオブジェクトがあったりするイメージです。

例えばCatalogItemControllerの処理で扱うリソースであるCatalogItemはDtoの中に置いてOKです。
GetXxxResponseやPutXxxRequestの中で、CatalogItemを共有すればよいだけです（共有できるなら）。
一番外側のDto（XxxRequest、XxxResponse）をリクエスト・レスポンスに応じてひとつずつ作ります。
中に複数のオブジェクトが含まれるのは全く問題ないです。

[KentaHizume]

@tsuna-can-se
念のため確認させていただきたく、
下記のようになるイメージで合っておりますでしょうか。

• Dto クラス

public class GetCatalogItemsResponse
{
    public required PagedList<CatalogItem> PagedListOfCatalogItem { get; set; }
}

• Controllerのアクションメソッドへの属性指定

[ProducesResponseType(StatusCodes.Status200OK, Type = typeof(GetCatalogItemsResponse))]

[tsuna-can-se]

@KentaHizume
あってます！
もちろん状況によってCatalogItem(Dto)を共有できないこともあると思いますが、その時はばらして作って構いません。

[KentaHizume]

@tsuna-can-se
ありがとうございます、
ただいま修正した場合どのようになるかを確認しております。
こちらに際して1点伺いたく、
命名をCatalogItemにしたところ、両方を参照する可能性のある箇所ではApplicationCoreのものかDtoのものかを区別するために下記のように若干冗長な形の実装になってしまうのですが、別の命名にしたほうがよさそうでしょうか。
（案）

• CatalogItemApiModel
• CatalogItemModel
• CatalogItemDto

public class CatalogItemMapper : IObjectMapper<ApplicationCore.Catalog.CatalogItem, GetCatalogItemResponse>

[KentaHizume]

@tsuna-can-se
修正版のレスポンスを確認したところ、現在より1階層深い形になってしまうのですが、
こちらは違和感ありませんでしょうか。

他の単純に1個取得する場合に、
下記のようなパターンで1層深くなってしまうものと、
そうならないものとが混在する可能性があることが問題ないか気になっております。

public class GetCatalogItemResponse
{
    public required CatalogItem CatalogItem { get; set; };
}

[tsuna-can-se]

@KentaHizume
はい、共通化を求めるならその形になります。
ただ、今回その形をどこまで追い求めるかは別問題だと思います。

やるとしたらXxxxApiModelでいいんじゃないですかね？
以下のように書いてありますし。

https://maris.alesinfiny.org/app-architecture/client-side-rendering/csr-architecture-overview/#application-architecture

[KentaHizume]

@tsuna-can-se
ご確認ありがとうございます。
Dto配下のドメインモデルの詰め替えに用いるクラス名については、
ドメインモデル名にApiModelを付加した命名にいたします。

@1nu1taichi
申し訳ありませんが、v1.0 のリリースまでにご指摘への対応が難しい状況で、
サンプルアプリの動作には関係しない箇所のため、v1.1 以降で対応いたします。

下記の通り issueを作成しております。

• Dtoのクラス名を規約に沿ったものに修正する #1740

[1nu1taichi]

@KentaHizume
ありがとうございます。ではこちらのPRは現時点で問題なしということでマージします。