Dressca管理アプリを作成する #1453
Comments
フロントエンド詳細
|
バックエンド詳細
|
全体像
|
共通パッケージの作成
import LoadingSpinner from "./components/LoadingSpinner.vue";
import assetHelper from "./helpers/assetHelper";
import currencyHelper from "./helpers/currencyHelper";
export { LoadingSpinner, assetHelper, currencyHelper}エントリーポイントを分割すると下記のエラーになってしまう。 https://nodejs.org/api/packages.html#package-entry-points 型定義ファイルが必要なように見えるが、
"exports": {
".": "./src/index.ts"
},
entry: resolve(__dirname, 'src/index.ts'),Vite公式ドキュメントの設定に寄せると型定義ファイルを要求するエラーになるので、型定義ファイルを作ったほうがよさそう。 推奨設定に寄せたが、UMD形式で出力する必要はなさそう。
またDresscaの使い方としては、CJS形式も不要なはずなので、 |
|
モノレポ構成でワークスペースを追加する際の手順をドキュメント化したほうがよいかもしれない。 |
|
・右上にドロップダウンメニューとリンクを作る 画面遷移とどこに更新、削除、追加の機能を持たせるかについて検討する。 |
|
バックエンド側のテストがないが、どこまで作る必要があるか検討する必要がある。 結合テスト 単体テスト |
型定義ファイルを出力する方法を探すvite-plugin-dts
tscを使う外部プラグインを使わずに済むのでこちらで対応 ただし、先にcommonのtscの実行を挟まないと型定義ファイルがなくてCIが死んでしまう |
CI用の依存関係の解決上記の問題について対策する。
順序の制御tscとビルド（Vite）でそれぞれ制御が必要 tsc
ビルド
aliasを追加する場合、直接 '@dressca-frontend/common': fileURLToPath(
new URL('../../packages/common/src/index.ts', import.meta.url),
), |
要議論ポイント
|
|
このissueで対応する範囲に関しては、一旦出そろった。 dependabotについては問題ないはずだが、マージ後に想定通り動作するか念のため確認する必要がある。
|
共通パッケージをUMD形式で出力する必要はあるか
|
|
別ポートでViteのプロキシサーバーを上げる場合はCypressも同じポートで上げるようにしておく必要がある。 package.json "test:e2e": "start-server-and-test dev http://localhost:6173/ 'cypress open --e2e --browser chrome'",
"test:e2e:ci": "start-server-and-test dev http://localhost:6173/ 'cypress run'",cypress.config.ts export default defineConfig({
e2e: {
specPattern: 'cypress/e2e/**/*.{cy,spec}.{js,jsx,ts,tsx}',
baseUrl: 'http://localhost:6173',
},
}); |
|
スレッドが長くなってきたためMSW関連は |
Entity FrameworkのDBとのマッピング現在Entity Framework上のEntityと、DDD上のEntityが偶然1:1対応しているが、1:1対応する必然性はない。 実装としては、
具体的には、
CatalogItemsの場合は、 Maia(MyBatis)の場合Maiaの場合は既にリポジトリでORマッパー上のEntityとDDD上のEntityを詰め替えるようになっている。
|
画面デザインデザインtailwind.configを設定するのが正しいらしい。 レイアウト業務アプリ向け画面なのでtoCアプリと被らないように。 機能
|
コンテキストごとにエンティティとアプリケーションサービスを分ける
現状
|
権限管理を行うレイヤーについて権限がドメイン知識かどうかに議論の余地があり、諸説ある。 具体的には、下記の2パターンが考えられる。
ただ、出典のリンク先が死んでいるが、
.NETで実装する場合、DIコンテナ経由で、ASP.NET Identityから提供されているインターフェース ASP.NET Identityを使用したチュートリアルでは、 [Authorize(Roles = "Administrator, PowerUser")]
public class ControlAllPanelController : Controller
{
public IActionResult SetTime() =>
Content("Administrator || PowerUser");
[Authorize(Roles = "Administrator")]
public IActionResult ShutDown() =>
Content("Administrator only");
}Spring Securityの場合
|
ドメイン
ユースケースユースケース図
ユースケース記述カタログアイテムの一覧を表示するアクター管理者、担当者 開始条件カタログアイテム一覧画面に遷移 事前条件ユーザーが認証されていること メインフロー
代替フロー
例外フロー事後条件カタログアイテムを更新するアクター管理者 開始条件カタログアイテム編集画面の更新ボタンを押下 事前条件ユーザーが認証されていること メインフロー
代替フロー
例外フロー
事後条件カタログアイテムを削除するアクター管理者 開始条件カタログアイテム編集画面の削除ボタンを押下 事前条件ユーザーが認証されていること メインフロー
代替フロー
例外フロー
事後条件カタログアイテムを追加するアクター管理者 開始条件カタログアイテム追加画面の追加ボタンを押下 事前条件ユーザーが認証されていること メインフロー
代替フロー
例外フロー
事後条件 |
画面URL
画面遷移
|
画面モックログイン画面
トップ画面下記の画面へのリンクを表示。
カタログ管理画面下記の2画面へのリンクを表示。
カタログアイテム一覧画面
カタログアイテム編集画面
カタログアイテム追加画面
ナビゲーションバーtoCのDresscaが横なのでわかりやすいように管理アプリは縦にする
|
認可
権限設計
ERerDiagram
User ||--|{ UserRole : ""
UserRole }|--|| Role : ""
Role ||--|{ RolePermission : ""
RolePermission }|--|| Permission : ""
User{
bigint Id PK
}
UserRole{
bigint Id PK
bigint UserId FK
bigint RoleId FK
}
Role{
binint Id PK
varchar Name
}
RolePermission{
bigint Id PK
bigint RoleId FK
bigint PermissionId FK
}
Permission{
bigint Id PK
bigint Name
}
|
シーケンス図
sequenceDiagram
participant Screen as カタログアイテム編集画面
participant Controller as CatalogController
participant CatalogManageAppService as CatalogManagementeApplicationService
participant CatalogItem as CatalogItem
participant CatalogRepo as CatalogRepository
Screen ->> Controller:更新ボタンを押下
activate Controller
Note right of Screen: PutCatalogItemsRequest
Controller ->> CatalogManageAppService: カタログアイテムを更新
Note right of Controller: カタログアイテムID<br/>アイテム名<br/>説明<br/>単価<br/>商品コード<br/>カテゴリID<br/>ブランドID
activate CatalogManageAppService
CatalogManageAppService ->> CatalogRepo:エンティティを取得
Note right of CatalogManageAppService: カタログアイテムID
activate CatalogRepo
CatalogRepo -->> CatalogRepo: DBアクセス（SELECT）
CatalogRepo -->> CatalogManageAppService: エンティティを返却
Note left of CatalogRepo: 更新前カタログアイテムエンティティ
activate CatalogManageAppService
CatalogManageAppService ->> CatalogItem: エンティティを更新
Note right of CatalogManageAppService: 更新前カタログアイテムエンティティ<br/>アイテム名<br/>説明<br/>単価<br/>商品コード<br/>カテゴリID<br/>ブランドID
activate CatalogItem
CatalogItem -->> CatalogItem: エンティティを更新
activate CatalogItem
CatalogItem -->> CatalogManageAppService: エンティティを返却
Note right of CatalogManageAppService: 更新後カタログアイテムエンティティ
activate CatalogManageAppService
CatalogManageAppService ->> CatalogRepo: カタログアイテムテーブルに永続化
Note right of CatalogManageAppService: 更新後カタログアイテムエンティティ
activate CatalogRepo
CatalogRepo -->> CatalogRepo: DBアクセス（UPDATE）
activate CatalogRepo
CatalogRepo -->> CatalogManageAppService: なし
activate CatalogManageAppService
CatalogManageAppService -->> Controller: なし
activate Controller
Controller -->> Screen: HTTP 204 No Content
|
決めるべきこと
認可モデルの定式化
認可のインターフェース
認可の判断の実装の選択肢認可の判断をするためには2つの情報が必要
分散モデルの場合 集中モデルの場合 推奨される設定a. IDプロバイダーを使用して認証する。 認可モデル
単純なモデル～複雑なモデル Relationship-Based Access Control (ReBAC) Attribute-Based Access Control (ABAC) 選択肢としては、 |
認可のインターフェースのアーキテクチャ案1. 既存のApplicationCoreに入れる分散モデル Dressca
├ Dressca.ApplicationCore
│ ├ ApplicationService
│ ├ ├ AdminAuthorizationApplicationService
│ ├ Authorization
│ ├ ├ User
│ ├ ├ Role
│ ├ ├ Permission
├ Dressca.Web
├ Dressca.Web.Admin2. 新しくAuthorizationパッケージを切る集中モデル 3. 別のサービスを上げる集中モデル |
|
別issueだが、パイプライン等での実行時は、npm install よりも npm ci （Clean Install）のほうがよい。 package-lock.jsonはルートのpackage.jsonと同じフォルダに作られ、 <SpaRoot>..\..\..\dressca-frontend</SpaRoot>
<SpaProxyLaunchCommand>npm run dev:customer</SpaProxyLaunchCommand>
<Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
<SpaRoot>..\..\..\dressca-frontend</SpaRoot>
<SpaProxyLaunchCommand>npm run dev:admin</SpaProxyLaunchCommand>
<Exec WorkingDirectory="$(SpaRoot)" Command="npm install" /> |
ログアウトボタンの実装App.vueからログアウト処理を呼ぼうとするとエラーで落ちてしまう。 authentication-serviceを下記のように修正すると解決する。
authentication-service.tsNGconst authenticationStore = useAuthenticationStore();
export async function logoutAsync() {
authenticationStore.signOutAsync();
}OK
export async function logoutAsync() {
const authenticationStore = useAuthenticationStore();
authenticationStore.signOutAsync();
} |
UnauthorizedErrorがうまくハンドリングできないエラーハンドラーの下記の箇所で、 routerがコンポーネントの外から使われているのがまずいらしいが、よい解決策が見つからない。 if (error instanceof UnauthorizedError) {
if (handlingUnauthorizedError) {
handlingUnauthorizedError();
} else {
const router = useRouter();
const routingStore = useRoutingStore();
routingStore.setRedirectFrom(router.currentRoute.value.path.slice(1));
router.push({ name: 'authentication/login' });
showToast('ログインしてください。');
}exportしてあるrouterを持ってくることで解決
⇒これをやると循環参照になってしまう。 |
vue-router周りの問題点1. エラーハンドラーからrouterをうまく操作できない既存のエラーハンドラーでも発生する。 2. 初回のログイン時、うまくルートに遷移しない/authentication/login から / に遷移してほしいが、ログイン画面から遷移しない。
console.log("リダイレクトパス")
console.log(routingStore.redirectFrom);
router.push({ path: routingStore.redirectFrom });
console.log("pushed");
authentication-serviceの中でawaitしていなかったのが原因。 |
|
B to CのCの意味として、CustomerよりもConsumerのほうが一般的なため、
|
|
yupのメッセージをコード上にべた書きしているので、多言語対応とは別に要修正
|
ロールの認可NGの場合のステータスコードを403から変更したい
下記の実装でかわりに404を返すようにカスタマイズできる？ カスタマイズできた、より詳しい回答もあった。 |
|
ここでHTTPステータスコードの変換処理を行うためのクラスを呼び出してます。 具体実装は以下のクラスしかなく、特に設定とかで書き換えることもできなさそうでした。 なのでMSページの案内方法以外の手段はなさそうですね。 |
|
@tsuna-can-se |
|
①フロントエンド用ブランチでpackage.jsonとpackage-lock.jsonを最新化（※このときnpm installしている） ④合体用ブランチに③で変更されたpackage-lock.jsonをコミット 最後にmainと合流するタイミングで解決すればよいとは思われるので、現象のみ記載。 |
アイテムの論理削除カタログアイテムの削除機能について、マスタ系のテーブルであるため、CatalogItemsテーブルのレコードは物理削除するのではなく、論理削除とするべき。 他のAPIに関しても論理削除されたアイテムをAPI経由で取得や更新できないようにするべき。 あわせてConsumer側も改修する必要がある。 公開フラグのようなもののほうがよい？ シナリオ
現状の注文（CheckoutAsync）フロー
Case1：注文できる買い物かごに入れた時点で有効なアイテムであれば、注文できてしかるべきと考える Case2：注文できない買い物かごに入れて1時間後に注文したら、販売が終わっていて買えなかった、というケースは不自然でない。 考慮ポイント
アイテムの状態細かく考えると下記の状態を持ちうる？
ただ、フラグ間の整合性を保つ必要がある そうなると販売中⇒（有効∧公開）は満たすべきか 要確認CatalogItemsテーブルに対してGetしている処理について、 |
アイテムが削除されていた場合の挙動調査、検討CatalogRepository.FindAsyncを呼び出すユースケースは下記の5つ。 CatalogDomainServiceに指定したアイテムIDがすべて存在するかチェックする (1)カタログ情報取得CatalogApplicationService.GetCatalogItemsAsync (2)買い物かご情報取得BasketItemsController.GetBasketItemsAsync (3)注文（チェックアウト）OrdersController.CheckoutAsync (4)買い物かごに追加ShopingApplicationService.AddItemToBasketAsync (5)数量更新ShoppingApplicationService.SetBasketItemsQuantitiesAsync (6)買い物かごから削除見落とし、BadRequestになってしまう Tobe整理期待値
現状
|
|
下記のissueについて、Adminにも反映する必要がある |
更新処理で、適合するカタログブランドとカタログカテゴリが見つからなかった場合の例外について
@KentaHizume |
web-adminのCatalogItemsControllerで発生が想定される401について
401が返ってきた際に、フロントエンド側でログイン画面にリダイレクトされる仕様になっているため、401で問題なし。 |
|
@kenjiyoshid-a catch (PermissionDeniedException ex)
{
this.logger.LogWarning(Events.PermissionDenied, ex, ex.Message);
return Unauthorized();
} |
概要
を実装するにあたり、楽観同時実行制御が適切な業務シナリオを検討した。
しかし、現在のBtoC向けのシナリオを中心とするDresscaアプリでは、
適切な業務シナリオがなさそうであった。
このことを解決するために、BtoB向けのシナリオを実現するDressca管理アプリを作成する。
具体的には、カタログアイテムの管理画面を作成し、CatalogItemsテーブルへのCRUD操作を行う機能を持ったアプリケーション一式を実装する。
詳細
この対応に伴い、npm workspace（フロント）とソリューションフィルター（バック）を導入する必要があるので、
それぞれ先行して別のissueで対応し、mainにマージする。
制約条件
完了条件
ブランチ管理
ソリューションフィルター追加後の状態をベースにして、
develop/admin 配下で下記の3本で管理中
関連タスクまとめ
Maia側の対応はこちら
先行タスク（マージ予定の順に記載、随時更新）
着手中
MSWを使ったフロントエンドの結合テスト
入力フォームのバリデーションのガイド作成（ガイドに従った実装にする）
エラーのレスポンスの方針、ガイド作成（ガイドに従った実装にする）
⇒仮実装済、論点あり
409をFilterで処理する
⇒仮実装済、論点あり
未着手
フロント
バック
別issueで対応
The text was updated successfully, but these errors were encountered: