ec-cube / ec-cube

EC-CUBE is the most popular e-commerce solution in Japan

EC-CUBE 4.2

4.1からの更新内容はリリースノートをご確認ください。

• 本ドキュメントはEC-CUBEの開発者を主要な対象者としております。
• パッケージ版はEC-CUBEオフィシャルサイトで配布しています。
• カスタマイズやEC-CUBEの利用、仕様に関しては開発コミュニティをご利用ください。
• 本体開発にあたって不明点などあればIssueをご利用下さい。
• EC-CUBE 3系の保守については、 EC-CUBE/ec-cube3にて開発を行っております。
• EC-CUBE 2系の保守については、 EC-CUBE/ec-cube2にて開発を行っております。

インストール

EC-CUBE 4.2のインストール方法

開発ドキュメントの インストール方法 の手順に従ってインストールしてください。

CSS の編集・ビルド方法

Sass を使用して記述されています。 Sass のソースコードは html/template/{admin,default}/assets/scss にあります。 前提として [https://nodejs.org/ja/] より、 Node.js をインストールしておいてください。

以下のコマンドでビルドすることで、 html/template/**/assets/css に CSS ファイルが出力されます。

npm ci # 初回およびpackage-lock.jsonに変更があったとき
npm run build # Sass のビルド

docker compose を使用している場合は以下のコマンドを実行してください

# 初回およびpackage-lock.jsonに変更があったとき
docker compose -f docker-compose.yml -f docker-compose.dev.yml -f docker-compose.nodejs.yml run --rm -T nodejs npm ci
# Sass のビルド
docker compose -f docker-compose.yml -f docker-compose.dev.yml -f docker-compose.nodejs.yml run --rm -T nodejs npm run build

JavaScript のビルド方法

フロントエンドで使用する JavaScript のライブラリは npm で管理されています。 JavaScript のライブラリは webpack でバンドル/minifyされます。 バンドルするライブラリを変更する場合は、テンプレートごとに以下の bundle.js を修正し、リビルドしてください。

• html/template/admin/assets/js/bundle.js
• html/template/default/assets/js/bundle.js
• html/template/install/assets/js/bundle.js

npm ci # 初回およびpackage-lock.jsonに変更があったとき
npm run build # Sass 及び JavaScript のビルド

JavaScript ライブラリのみをビルドしたい場合は以下でも可能です。

npx webpack

docker compose を使用している場合は以下のコマンドを実行してください

# 初回およびpackage-lock.jsonに変更があったとき
docker compose -f docker-compose.yml -f docker-compose.dev.yml -f docker-compose.nodejs.yml run --rm -T nodejs npm ci
# Sass のビルド
docker compose -f docker-compose.yml -f docker-compose.dev.yml -f docker-compose.nodejs.yml run --rm -T nodejs npm run build
# JavaScript ライブラリのみのビルド
docker compose -f docker-compose.yml -f docker-compose.dev.yml -f docker-compose.nodejs.yml run --rm -T nodejs npx webpack

動作確認環境

• Apache 2.4.x (mod_rewrite / mod_ssl 必須)
• PHP 7.4.x / 8.0.x / 8.1.x
• PostgreSQL 10.x or higher / MySQL 5.7.x or 8.0.x
• ブラウザー：Google Chrome

詳しくは開発ドキュメントの システム要件 をご確認ください。

ドキュメント

EC-CUBE 4.x 開発ドキュメント@doc4.ec-cube.net

EC-CUBE 4.x 系の仕様や手順、開発Tipsに関するドキュメントを掲載しています。 修正や追記、新規ドキュメントの作成をいただく場合、以下のレポジトリからPullRequestをお送りください。 https://github.com/EC-CUBE/doc4.ec-cube.net

開発への参加

EC-CUBE 4.2の不具合の修正、機能のブラッシュアップを目的として、継続的に開発を行っております。
コードのリファクタリング、不具合修正以外のPullRequestを送る際は、Pull Requestのコメントなどに意図を明確に記載してください。

Pull Requestの送信前に、Issueにて提議いただく事も可能です。 Issuesの利用方法については、こちらをご確認ください。

Slackでも本体の開発に関する意見交換などを行っております。

コピーライトポリシーへの同意

コードの提供・追加、修正・変更その他「EC-CUBE」への開発の御協力（Issue投稿、Pull Request投稿など、GitHub上での活動）を行っていただく場合には、 EC-CUBEのコピーライトポリシーをご理解いただき、ご了承いただく必要がございます。 Issueの投稿やPull Requestを送信する際は、EC-CUBEのコピーライトポリシーに同意したものとみなします。

ec-cube's Issues

デザインテンプレートの探索機能の仕様検討

通常利用しているデザインテンプレートが存在しない場合に、他のデザインテンプレートを探す仕組みを検討中

背景

３系では、アップデートに対応したいので、以下の事が考えられる

• デフォルトで持っているデザインテンプレートのファイルを直接編集することはNG
• アップデート後に新たに追加されたページが表示されるように、現在利用しているデザインテンプレートで存在しないテンプレートは、デフォルトを参照しにいくなどが必要
• 利用しているテンプレートがデフォルトのアップデートの影響をうけてしまわないような作りが必要（本体のバージョンアップで変わる可能性のあるjQueryはデザインテンプレートに同梱された物を使うなど）

探索順位案

順位	パス案	説明	生成イメージ
1	/template/CCC	ユーザーが指定したテンプレート	管理画面から編集可能
2	/src/Eccube/Resource/CCC	ユーザーが指定したテンプレートの原本	オーナーズストアで買った状態そのまま
3	/plugin関係のファイル	プラグインが求めているテンプレート	プラグインで用意された原本
4	/src/Eccube/Resource/default	EC-CUBE標準のテンプレートの原本	本体のアップデートで変更される。

コーディング規約についてのご意見箱

Wikiに、[EC-CUBE3　機能要件]と[開発要件]の２つのページを作成いたしました。
[EC-CUBE3 機能要件]は変更が入ることはほとんどありません。

[開発要件]について、意見をいただきたく本Issueを作成いたしました。
[開発要件]は本リリースまで適宜ブラッシュアップをしていきたく、皆様のご意見をこちらで集約させていただきたいと思います。

robots.txtを設置する

そもそも設置する/しないの話から皆様のご意見を頂戴できればと思います。

eccube_install.sh mysql で文字化けする

eccube_install.sh mysql でインストールした場合に、 DBの文字エンコーディングが laten1 等になっていると文字化けしてしまう。

明示的に utf8 を指定した方が良い

admin などの後ろの "/" について

一般的なRESTful URLでは / をつけない方が多いと思いますが、SymfonyのSecurity を使った際に /admin のみだと /adminxxx など前方一致となるため、 2系の index.php の省略の場合には後ろの / までをURLとした方が良いかと思います。

Directory Structure について

今後のDirectory Structureについて、何か指針はありますでしょうか。
大幅に構造が変わるようですので、わかりやすく、トレンドな感じにまとめてはいかがでしょうか。

eccube_install.sh の調整

• 環境毎に調整が必要な値のデフォルト値の修正汎用的なものにする
• test.local 等ではなく eccube-vagrant に合わせるか、localhost のように汎用的なホスト名とする、もしくは必須入力とする。DB_NAME等も同様
• エラーがでている
  • chmod: cannot access `./src/Eccube/page': そのようなファイルやディレクトリはありません
  • ERROR: リレーション"dtb_bloc_bloc_id_seq"は存在しません
    行 1: SELECT SETVAL ('dtb_bloc_bloc_id_seq', 10000);
  • ERROR: リレーション"dtb_pagelayout_page_id_seq"は存在しません
    行 1: SELECT SETVAL ('dtb_pagelayout_page_id_seq', 10000);
    他。
• 一番上の使い方のコメントが間違っている。

インストール方法

しばらくインストーラーも動作しない感じで、実際の動作を試せていないのですが、どんな感じで環境構築するのでしょうか?

Testの整備

現在、歴史的経緯からとお見受けしますが、testとtestsに分かれておりわかりにくいと思います。
テストのカバレッジもあまり良くない状況だと思います。

こちらについて、何か整備指針などはありますでしょうか。

フレームワークの利用の検討

ルーティング機能やDBマイグレーション機能など、これだけの大幅な変更を加えるのであれば、いっそのことフレームワークの利用を検討してみては如何でしょうか。

インストーラ使ったインストールを行うと管理画面ログインできない

ざっと作ったため、管理画面にログインできない状態です。
近々直しますので、開発されている方はそれまでeccube_install.shでインストールしてください。

管理画面のデザイン変更・メニュー構成変更

下記イメージで管理画面を実装する

• システムに関する項目はすべて「設定」タブにいれる
• レスポンシブ対応

不明な DEFAULT

dtb_products_class.product_type_id
初期で使われていない0が初期値。データ移行で不正なデータが発生して発覚。とりあえず削除する。1でも良い気もする。

drop_table.sql エラーとならないように

直接実行を考慮

何故かtest.localへリダイレクトされてしまう。

eccube_install.shを環境に合わせて編集し、スクリプトを実行したにもかかわらず、
http://xxx.xxx.xxx/
（eccube_install.shに記述したURL）にアクセスすると、http://test.local/にアクセスしてしまい、エラーとなってしまします。
他に修正すべきファイルがあるのでしょうか？

Model クラスの実装

改善したい点は数多く有りますが、ひとつだけ挙げるならこれです。

ページクラスからビジネスロジックを切り離し、処理の対象毎にまとめて Model クラスとして再構築します。

また、従来からのコードで Model と同様の働きをするクラスを Model として再定義します。
例）
SC_Product → ¥Model¥Product¥Product
SC_Helper_Category → ¥Model¥Product¥Category
SC_Helper_Purchase → ¥Model¥Order¥Order
SC_Customer → ¥Model¥Customer¥Customer

autoloaderの実装

data/ClassLoader.phpを作成し、全classをautoloadできるようにする

mtb_系統をひとつのテーブルで取り扱う

• 構造の違うmtb_系テーブルを除き、ひとつのテーブルとする。
• 既存の各テーブルを分けるために、「type」カラムを用意する。

ただし、id, name, rank以外の構造のmtb_（mtb_constants / mtb_zipなど）は別table（constants / zip）とする

システム要件

取り急ぎ把握したいのは、PostgreSQL のバージョンなのですが、諸々どこかにまとまっていましたっけ?

テーブル命名規則の変更

テーブルについているprefix「dtb_」「 mtb_」をはずす

商品詳細ページにて「カートに入れる」ボタンを押すとページがみつかりません。

商品詳細ページにて「カートに入れる」ボタンを押すとページがみつかりません。

Routerの実装

• 実装時には下記３つのファイルを使用する
  • html/index.php：html/router.phpを読み込むのみ
  • html/router.php：ルーターのロジック（定義ファイル以外読み込まない）
  • html/routes.php：ルーティング定義ファイル
• URLをparseし、対応したclassを呼び出す
• html/routes.phpの定義は以下の通り

$arrMaps = array(
    array(
        'method' => 'GET|POST',
        'path'   => '/',
        'dir'    => '',
        'class'  => 'index'
    ),
    array(
        'method' => 'GET|POST',
        'path'   => '/products/detail',
        'dir'    => 'products',
        'class'  => 'detail'
    ),
    array(
        'method' => 'GET|POST',
        'path'   => '/admin/',
        'dir'    => 'admin',
        'class'  => 'index'
    ),
    array(
        'method' => 'GET|POST',
        'path'   => '/admin/login',
        'dir'    => 'admin',
        'class'  => 'login'
    ),
);

DBスキーマの移行サポートについて

今まで、EC-CUBEではDBのスキーマを変更した際にmigrationを作成していませんでしたが、今後は何からの形でcommitに含めませんか？

バージョンアップしやすいように開発することも安全なウェブシステムに重要ではないでしょうか。

AppVeyor (appvoyer.yml) 対応

AppVoyer だとテストがこけるのでappvoyer.ymlの修正が必要です。

参考
https://ci.appveyor.com/project/ttsuru/ec-cube

`app/cache` 以下の `.gitkeep` について

app/cache/ 以下はそれぞれのロジックで自動的にディレクトリが作られるので、トラブルやインストールの簡素化のためにも、cache のみをパーミッション777で置いておくようにしてはどうでしょうか。

ログの処理を monolog で行う

ログの処理を monolog を用いて行いましょう。
https://github.com/Seldaek/monolog

swiftmailerのバージョンを上げる

Security Bug fixされているバージョンにあげる

see https://scrutinizer-ci.com/g/EC-CUBE/ec-cube/issues/eccube-3.0.0-beta/files/composer.lock?orderField=path&order=asc#inspectioncomment-684225486

Travis CI / Coveralls 対応

Travis CI
https://travis-ci.org/EC-CUBE/ec-cube

Coveralls
https://coveralls.io/r/EC-CUBE/ec-cube

Coveralls については連携がなかったようです。
また、バッジも貼り付けてはどうでしょうか。

[![Build Status](https://travis-ci.org/EC-CUBE/ec-cube.svg)](https://travis-ci.org/EC-CUBE/ec-cube)
[![Coverage Status](https://img.shields.io/coveralls/EC-CUBE/ec-cube.svg)](https://coveralls.io/r/EC-CUBE/ec-cube)

eccube_install.sh の HTTP(S)_URL のデフォルト値

• test.local ではなく eccube-vagrant に合わせる、もしくは localhost のように汎用的なホスト名とする、もしくは必須入力とする。
  • #62 のようなトラブルに苦しむ人がいるので。。。
• HTTP_URL の最後に / が無い

PDF出力系ライブラリを何にするか

必須条件

• 日本語対応している
• カスタマイズが容易

理想

• ミリ単位での指定ができる
• Packagistに登録されている

候補

• fpdf
• mPDF
• ThinReports
  などを検討していますが、長い目で見てどれがいいか議論の上で決定したいと思います。

ローカル変数の取り扱い

action()内では、カウンタ変数以外のローカル変数を許容しない
必ず、クラス変数とすること

Silexベースのコードへのリファクタリング

Silexベースのコードへのリファクタリングの進捗とその疑問点などをまとめるIssue

リファクタリングへの参加方法

1. 下のリファクタリング対象一覧の確認
2. 自分が対応したい画面のAssigneeにGitHub IDを記載
3. リポジトリをフォークし、フォークした自分のリポジトリでブランチを切って開発
4. 開発完了後、PullRequestを送信する（Pull Request前にテストコードを作成することを推奨）

• リファクタリング対象一覧
  https://docs.google.com/spreadsheets/d/1df5Sc4eoEQv4ZVm6_q8-QE0-PduS2gnAtNXVQco0x-8/edit?usp=sharing

リファクタリングのルール

• リファクタリングガイドラインを参照
• 不明点はIssueのコメントやSlackを活用

プラグインで利用できるフックポイントと実行順序

DocumentとしてFIXしてしまう前に、現在開発しているプラグインのフックポイントと、その実行順序について、覚書程度に記載します。

フックポイントの命名規則

eccube.event.*.(before|after|finish)

現時点で、自動生成もしくは定義されているフックポイント一覧

• eccube.event.app.before
• eccube.event.app.after
• eccube.event.controller.ROUTE.before
• eccube.event.controller.ROUTE.after
• eccube.event.controller.ROUTE.finish
• eccube.event.render.before
  • $app['view']->render() のときにEventが走る。
  • 引数のEventObjectを利用することで、ソースコードを自由に触れる用にしてある

ROUTE は、 $request->attributes->get('_route') で取得できる、ルーティング名
->bind('ここ')

実行順序

1. eccube.event.app.before
2. eccube.event.controller.ROUTE.before
3. eccube.event.render.before
4. eccube.event.controller.ROUTE.after
5. eccube.event.app.after
6. eccube.event.controller.ROUTE.finish

同一のフックポイントを利用している場合は、EventSubscriberで定義した優先順位による

これから実装するところ

• 各Form\Type

EC-CUBE3　β版admin画面について

EC-CUBE3β版のインストールを行いましたが404エラーとなりadminが表示されません。
http://[URL]/html/adminと入力しています。
商品購入のトップ画面は表示されます。
html/adminを認識していないようですが、インストールを失敗しているのでしょうか？
html/adminの中はload_module_config.php　load_plugin_config.php　require.php　cssとなっています。
パスか環境設定の問題だと思うのですが、対処方法があればご教示下さい。
よろしくお願いします。
なお、環境は下記の通りです。
centOS7
apache 2.4.6
PHP 5.4.16
MariaDB

ORMの利用

DoctrineORM DoctrineDBALなどのORMの利用を積極的に検討

懸念点・判断基準は以下。

• 性能面：著しく実行速度が遅くならないか
• MySQL/PostgreSQLのauto incrementの違いを吸収するか
• 生のSQLを投げて実行させることができるか

候補は以下？他に候補があれば、コメントください。

• Doctrine ORM
• Doctrine DBAL

DIコンテナの利用を検討

以下の議論でも挙がっていますが、
#7 (comment)
#7 (comment)

DIコンテナを使えば、依存関係も上手く制御できると思います。（テストも書きやすくなります。インターフェースを考えなおす良い機会にもなるでしょう。）是非、検討して頂ければ幸いです。

テンプレートエンジンを使うのか

テンプレートエンジンをそもそも使うかどうか、
使うとすれば何を使うか

デフォルト機能のプラグイン化

2.13系にデフォルトで含まれている機能だが、

• ECとしての役割がうすいもの
• フラグでON/OFF切り替えているもの

を、デフォルトでインストールされているプラグインとして扱う

• 商品レビュー投稿機能
• ポイント機能

モックの開発と、そのレビュー

私が、2/13(金)目途で、以下の構成の注文ロジックのモックを作成します。
その後、WIPとしてPR投げますので、皆様にモックをレビューしていただきたいと思います。

レビューを重ね、PRが問題ないと判断でき次第、そのPRを本リポジトリにマージします。
その後、マージしたPRをサンプルコードとして提示したいと思います。
Sessino, DataBaseについては、どの機能を開発するにあたっても、必要になってくると思いますので、
随時見直しをしていきます。
疑問に思ったり、変えたいときは、別途Issueをたててください。

---

• ディレクトリ(レイヤー)構成
  • Repository - DB操作
  • Service - ビジネスロジック
  • Controller - ViewとServiceつなぐ
  • View
  • Plugin - 上記を包含するものか、別構成にするか検討
• クラス構成
  • Repository
    • CustomerRepository
    • ProductRepository
    • etc
  • Service
  • Controller
    • 機能単位
  • View
    • 画面単位
• Event
  • どこでどういう形で利用するか要検討

---

• Session
  • cart
  • auth
• DataBase
  • テーブル設計

テーブル定義書・ER図

2.13 では、2つありましたが、まとめた方が良いのかなと。

• docs\テーブル定義書(EC-CUBE2.13dev).xlsx
• docs\table_definition.xls

個人的には、前者は Excel 方眼紙で勝手が悪かったので、最近は後者を重宝しています。

今後の保守方針に関して、Excel 直書きなのか、ツール生成なのかといった当たりも明確にしたほうが良いように感じます。(docs\ER-D\README.md みたいに、なっていると分かりやすいですね。)

EC-CUBE 上の用語との差異も散見するので、統一していくのも必要かと考えます。

合わせて、html\install\sql\comment_set_pgsql_2.13.sql の保守も課題でしょうか。
#22 あたりとも関わりますかね。

Vagrant との連携

Vagrant を利用して、簡単に開発環境を構築できるようにする

See Also.

https://github.com/nanasess/vagrant-lamp

導入方法を明記する

インストールマニュアルがないため、作成する。

• Git版(composer利用する)
• Package版(.tar.gz, .zip)

テストの対象範囲について

βリリースまでは、開発スピードを重視し、以下をテスト基準にしようと思いますが、いかがでしょうか？

特に、src\Eccube\Service\は、ビジネスロジックがほぼすべて集約されるため、最重要と考えています。
そのため、src\Eccube\Service\以下は、カバレッジ100%にしていきたいです。

• 疎通確認（Routing）テスト
  • 全正常系/異常系を網羅
• src\Eccube\Service\に属するClassの単体・機能テスト
  • 単体テスト100%
  • 機能テスト100%
• src\Eccube\Form\Type\に属するClassの機能テスト
  • Validationチェック
• src\Eccube\Plugin\に属するClassの単体・機能テスト
  • Plugin詳細が決まり次第

上記に含まれていない、

• src\Eccube\Controller\
  • ビジネスロジックを持たせないように作成していくため
• src\Eccube\View\
  • カスタマイズ前提で、テストされている意味が薄いため
    以上を理由に、テストをマストにしていません。

βリリース以降では、上で挙げたもの以外も対象にしていきたいと思います。

👍 や 👎 だけでもコメントいただけると判断しやすいです。

商品データ構造の変更案

前々からやりたかった事で、やれと言われたのでこの機会にやっちゃいます。
前に合宿でとりあえず商品一覧動くまでやったのがコレです。
chihiro-adachi#2

データ構造の柔軟性と、検索や表示の高速化を実現するために、concrete5と同じ様な仕組みにしたいと思っています。（ こんなんです > https://github.com/concrete5/concrete5-5.7.0/blob/develop/web/concrete/src/Page/PageList.php ）
ざっくり言うと、正規化しまくって検索用のインデックステーブルを作る感じです。
これにより、管理画面側に商品属性の管理機能が必要になります。

それと、現在のdtb_produtsは商品マスタではなく、dtb_product_classが商品マスタに該当するという認識があるので、
dtb_product_class > dtb_produts
にしています。

とりあえずこの方針でやって良いとは言われたのですが、皆さんのご意見も聞きたいので、よろしくお願いします。

ページレイアウトを取得できない

https://www.uploady.com/#!/download/IPRHKtYjq4h/Uz81izfLasnDJziu

WebAPIを実装する

認証

OAuth 2.0？SAML？要検討

通信方式(REST)

HTTP メソッドをリソースの操作とする。

• POST：create
• GET：read
• PUT：update
• DELETE：delete

URL

例）/api/[リソース]/

• 顧客IDの一覧を取得する

    GET ~/api/customer/

• 新規の顧客データを作成する

    POST ~/api/customer/

• [DB系] ※要検討
  • /api/db/customer/
  • /api/db/product/
  • /api/db/order/
• [振る舞い系] ※要検討
  • カート情報確認
  • カートに入れる
  • カート削除
  • お届け先の指定
  • 支払方法、お届け日時の指定
  • 購入情報最終確認
  • ログイン /api/login/
  • ログアウト /api/logout/
  • メール送信

パラメータ

パラメータはJSON形式で渡す。

GETパラメータ例

~/api/customer/?json=
{
    include: [ "id", "name", "*"],      // 取得するカラム
    filter: {
        "name": ["test", "aaaa", "test example"],          // name に test と example を両方含む
          // -> where name = test or name = aaaa or (name = test and name = expamle)
        "kana": ["hoge"]
          // -> and kana = "hoge"
    },
    sort: {"id":"asc", "create_date":"desc"}, 
    limit: 50,
    offset: 100,
}

POSTパラメータ例

~/api/customer/?json=
{
    include: [ {"name":"ほげほげ"}, {"kana":"ホゲホゲ"}]
}

PUTパラメータ例

~/api/customer/?json=
{
    filter: {
        "id": "1",
        "name": "test example",          // name に test と example を両方含む
        "name": [ "1test", "example" ]   // name が test または example に完全一致
    },
    include: [ {"name":"ほげほげ"}, {"kana":"ホゲホゲ"}]
}

DELETEパラメータ例

~/api/customer/?json=
{
    filter: {
        "id": "1",
        "name": "test example",          // name に test と example を両方含む
        "name": [ "1test", "example" ]   // name が test または example に完全一致
    }
}

レスポンス

パラメータはJSON形式で渡す。

• HTTPステータスコード「200,201」：OK (POSTの場合のみ、201)
• HTTPステータスコード「200,201以外」：NG

APIの処理の結果	ステータス・コード	Body
対象データの取得・削除に成功した場合	200 OK	対象となるデータが格納される {success: true, customer:{"id":xxxx,…}, error_message: ""}
対象データの追加に成功した場合	201 Created	{success: true, error_message: ""}
対象データの更新に成功した場合	200 OK	{success: true, error_message: ""}
リクエストに検証エラーが存在する場合	400 Bad Request	検証エラー情報が格納される {success: false, error_message: "xxxx"}
対象データが存在しない場合	404 Not Found	{success: true, error_message: ""}
メソッド内で例外が発生した場合	500 Internal Server Error	エラー情報が格納される {success: false, error_message: "xxxx"}

.gitignore の追加

.gitignore を作成します。

CartService/OrderServiceの作成

購入フローから注文完了までのビジネスロジックを @chihiro-adachi と二人で進めていってます。

SC_XXXX系の登場人物が多いため乗せ換えが難しく、なおかつ、今のロジックのまま開発を進めるより、オブジェクト設計・フロー設計を合わせて見なおしたほうがいいと判断したため、リファクタ込で進めていっております。

具体的には、以下の作成をしています。

• CartService
  • カートセッションの管理クラス
• OrderService
  • 注文まわりの管理クラス

乗せ換えフェーズの原則から外れるイレギュラーな対応となるため、周知の意味で取り急ぎIssueをたてさせていただきます。

ER図

まずは 2.13.x ベースのものを追加

購入フローの短縮化

購入フローのステップを短縮化する。