背景
Hard/Super Hard扱いの機能をすべてBe/BEARネイティブでフルスクラッチ再実装すると、EC-CUBE互換の細部（PDF帳票、CSVフォーマット、メール文面、template/plugin/file副作用）を再現するコストとリスクが大きい。
一方で、既存EC-CUBE/Symfony由来コードをそのままHTTP Controllerとして露出するのではなく、ソースディレクトリと依存境界を隔離したうえで、BeMart側からは小さなinterface/serviceとして呼び出す形にすれば、互換性を保ちながら本体設計を汚さずに移植できる。
方針
- BeMart本体のResource / Be Input / Finalは薄いadapter呼び出しに留める。
- EC-CUBE由来コードは隔離ディレクトリに配置する。
- 候補:
src/Imported/Eccube/...
- 互換service wrapper:
src/Compatibility/Eccube/...
- namespace変更は最小限から始める。
- まずはEC-CUBE由来コードの依存解決を優先する。
- BeMart側公開面は独自interfaceで固定する。
- Symfony依存はcompatibility層の中に閉じ込める。
- BEAR ResourceからSymfony container/controllerへ直接依存しない。
初期対象
- PDF
admin_order_export_pdf- 既存PDF生成ロジック/TCPDF設定/帳票レイアウトを隔離サービス化する。
- CSV export/import
- 商品/会員/受注/配送/規格系CSV
- EC-CUBE互換フォーマットとstreaming/download境界をadapter化する。
- Mail
- 送信本文生成、テンプレート解決、通知メール送信をcompatibility service化する。
- Template管理
- template install/download/delete/selectなどfile副作用のある操作をadapter化する。
- Plugin lifecycle
- install/enable/disable/uninstallはSymfony/EC-CUBE互換層で扱う。
- 将来のBe/BEAR向けplugin APIとは分ける。
実装ステップ
受け入れ条件
- BeMart本体のResource/Be層がSymfony APIに直接依存しない。
- EC-CUBE由来コードの置き場所と責任がREADME/docsに記録されている。
- 少なくともPDFパイロットがActionRedirectではなくcompatibility service経由で到達する。
composer psalm と composer tests が通る。- status HTMLで、adapter採用理由と確認結果が追跡できる。
非目標
- すべてを一度にフルスクラッチでBe/BEARネイティブ化しない。
- 既存EC-CUBE ControllerをそのままHTTP routeとして公開しない。
- 新しいBe/BEAR向けplugin API設計と、既存Symfony plugin互換層を混同しない。
背景
Hard/Super Hard扱いの機能をすべてBe/BEARネイティブでフルスクラッチ再実装すると、EC-CUBE互換の細部（PDF帳票、CSVフォーマット、メール文面、template/plugin/file副作用）を再現するコストとリスクが大きい。
一方で、既存EC-CUBE/Symfony由来コードをそのままHTTP Controllerとして露出するのではなく、ソースディレクトリと依存境界を隔離したうえで、BeMart側からは小さなinterface/serviceとして呼び出す形にすれば、互換性を保ちながら本体設計を汚さずに移植できる。
方針
src/Imported/Eccube/...src/Compatibility/Eccube/...初期対象
admin_order_export_pdf実装ステップ
native / adapter / legacy compatibility / out-of-scopeに再分類する。src/Imported/Eccubeとsrc/Compatibility/Eccubeの配置ルールを決める。OrderPdfCompatibilityInterfaceのようなBeMart側interfaceを定義する。受け入れ条件
composer psalmとcomposer testsが通る。非目標