--- titles: phase.2、機能詳細想定 tags: RD --- # phase2機能詳細想定 徒然なるままに日暮。 マイクロサービス毎に、こう売るならこうつくればいいんじゃね的な脳味噌アウトプット。 未整理事項ばっかり :smirk_cat: phase.1のところには、==ビジネス側がどう転んでも対応できる土台==の観点で描いてみました。 --- ## 会員 ### case: GW-PRAMSオムニDBを推して売っていく - GWで作っているハズのcongito認証は再利用し、業種、ユーザ特有の情報については会員マイクロサービス配下で独自データ管理。 - cognitoユーザと独自データの紐付けはmail-addressでいいんじゃないかな。会員番号とか持ちたくないし、採番とかむだ。 - document形式が適用しやすそう。 - 基本会員番号で全量取得して表示するだけ。 - 月一回の集計くらいならなんとでもなるでしょ・・・。 ### case: 相手方システムの会員データを活用していく - 業種、ユーザ特有の情報だけ会員マイクロサービス配下で独自データ管理。 - 相手型のデータ管理型にも寄るが、結局mail-addressで紐づけるのがいいんじゃないかな。 - mail-address重複は基本NGとして、すでに重複しているデータに対応するだけのために、紐付け用第二キーに無意味連番持てばいいんじゃね。 ### case: 新ECで独自開発。 - 好きに作れるので、どうにでも。 ### phase.1 - 相手方に会員管理がない場合を想定したcognitoによる会員（名前、住所等どんなビジネスの会員でも登録する共通項のみ）管理の実装。 - いろいろなユーザ特定キーに紐づけられる会員属性情報と会員の行動履歴と会員の所有物（ポイント、クーポンなど）の１パターン実装。 --- ## 契約 ### case: 相手方システムと新ECで機能を共存させていく - 業務フローを成り立たせるために最低限必要なマイクロサービス’sがあるはずなので、おすすめしにくい。 - やるとしたら、業務フローを実装するBFF(Backends For Frontends ~~Best Friend Forever(ズッ友)~~)もシステムとして提供し、この層をカスタマイズしていくのがいいんじゃないだろうか。 - 要は相手システムをラッピングしてしまう感じ。 ### case: 既存パッケージと組み合わていく - 相手方システム共存型とあまり変わらないが、どちらかというとこっちのcaseの方が新EC比率が少ないと考えられる。 - 倉庫の入庫出庫指示とささげくらいじゃないカナ・・・。既存パッケージと組み合わせて売れるのは・・・。 ### phase.1 - 業務フローから呼び出されるAPI単位のBFF層を作っておき、必要なAPI（契約機能）を成り立たせるマイクロサービスの組み合わせを管理・編集できるようにしておく。 - システム提供する機能を有効にするたびに、必要マイクロサービスを動的に表示できるようにしておいて、契約時のお値段の導出のインプットとできるようにしておく。 --- ## 受注 ### case: 注文データは相手方システムで作って、情報連携し、BO業務（注文キャンセル、返品、集計、出庫発送指示などなど）だけ売っていく - 注文変換・取込できるアップロード機能（Drag&Dropがいいよねー）を実装。 - ファイル転送による受領からの自動「変換・取込」も欲しくなるはず。 - 現時点での注文の全量をアウトプットする機能を実装。 ### case: 注文を相手方フロントで取って、新EC-APIをたたいて注文登録していく。 - 至って普通の実装。 ### phase.1 - 注文データ作成のBFF層を実装。（片方はFrontendじゃないけど・・・） - 注文データから後続処理の業務フローも実装するが、デフォルトとして新EC機能を呼び出し続けるか、途中停止して相手方システムへ後続連携するか選べるようにしておく。できればフローの途中途中で選択点があると良いかも。 - CS業務として実施する注文検索・修正・キャンセルはどんな売り方でも必要なので作っておく。 --- ## 出荷 ### 既存パッケージでフロント、BO業務をやってしまい、倉庫だけAMS管理下の物を使う。 - 出荷指示API、在庫確認単独API、在庫照会（全量＆変動分）APIを実装。 - 相手方システムの出荷実績を登録する何かを叩くところは個別実装。 - 相手方システムの発送実績を登録する何かを叩くところは個別実装。 ### phase.1 - 受注から出荷指示を自動生成する。 - 出荷指示を倉庫側に伝える機能を実装する。 - ~~出荷実績を受け取り何かを呼び出すAPIを提供する。~~ --- ## 商品 ### 新ECを完全に相手に運用してもらう - 新規登録テンプレート（アパレルならアイテムカテゴリー毎に、ある程度中身の埋まってる物）からの新規登録。 - ログインユーザが過去に登録した商品からの参照新規登録。 - こんなのがないと相手には使ってもらえないとおもう。 ### 商品登録のオペレーションを人を出してやる現在のビジネスを継続する。 - EXCELドーンとうろく。 ### phase.1 - APIとは切り離した形で商品登録のできる機能を開発しておく。 - 上記を叩く口として、画面からのAPIだったり、EXCEL処理のバッチだったりすれば良い。 --- ## 販売 ### 商品は相手方システムで作るけれど、陳列設定は新EC - 商品取込は商品マイクロサービスでやっておく。 - ので、販売の計画はどういう売り方でも一緒。 ### 販売の計画まで相手方システムや既存パッケージでやるが、フロントだけ新EC。 - そんな売り方はちょっと勘弁してほしい・・・。 ### phase.1 - 商品と同じで、販売計画テンプレート、登録履歴からの参照新規登録を実装する。 --- ## 販売促進 ### 分析、立案は相手方システムや既存パッケージでやるが、ECサイト適用は新EC - 注文変換・取込できるアップロード機能（Drag&Dropがいいよねー）を実装。 ### 分析も新EC - よそのパッケージを適用する提案をした方がいいとおもう。 ### phase.1 - APIとは切り離した形で販売促進登録のできる機能を開発しておく。 - 上記を叩く口として、画面からのAPIだったり、EXCEL処理のバッチだったりすれば良い。 --- ## その他issue ### 登録失敗によるロールバック。 何らかの登録行為は全てissueNo+(ins or del)を必須とし、issueNo毎に戻せる機構を実装する。 従来のupdateでの実装は全て、過去レコードの論理削除と新規レコードのinsertで実装すれば状況の実現は可能。