背景 — プラグイン機構のジレンマ
EC-CUBE のプラグイン機構を BeMart (BEAR.Sunday + Be Framework) へどう扱うかには、一見 2 択しかない:
- 忠実移植 — EC-CUBE のプラグイン機構 (Symfony EventDispatcher / Doctrine trait によるコアエンティティ拡張 / proxy codegen) を BEAR.Sunday に取り込む。しかしこれらの機構自体が、この移植が解消しようとしているアーキテクチャ問題の発生源。忠実移植は 病気を取り込む。加えて Doctrine trait 拡張は
final readonly エンティティと構造的に両立しない。
- 放棄 — プラグイン機構を捨てる。しかし EC-CUBE のプラグイン・マーケットプレイス (数百の既存プラグイン) は EC-CUBE 最大の資産の一つ。放棄は エコシステムの非連続を意味する。
提案 — 第三の道: Anti-Corruption Layer による隔離
腐敗レイヤーを「除去」も「取り込み」もせず、検疫する:
- 旧 EC-CUBE 4.3 ランタイムを消さず、隔離された恒久的サブシステムとして保持し、そこをプラグイン・エコシステムの宿主にする。
- BeMart (BEAR.Sunday) はクリーンな核であり続け、必要な capability を クリーンなブリッジ (Anti-Corruption Layer) 越しに legacy サブシステムへ要求する。
- 腐敗は境界を越えない → BEAR.Sunday の
final readonly / Be Framework の純度は保たれる。
- 通常の Strangler Fig (旧が消えゆく過渡状態) と異なり、これは legacy を恒久的な bounded subsystem として意図的に残すアーキテクチャ。
なぜ実現可能か — 土台は既に 2 つ敷かれている
- 厳密移植が legacy 同居を可能にした。 BeMart は
dtb_*/mtb_* スキーマを一切変えていない。本物の EC-CUBE 4.3 ランタイムが 同一 DB に対してそのまま走れる。「legacy を生かし続ける」の最難関＝データ乖離は、別目的 (クリーンな SQL) で下した厳密移植の決定によって既に解けている。
EccubeSharedSessionAdapter が実証済みの primitive。 ProdSessionOverrideModule が SessionInterface → EC-CUBE セッションのアダプタを既に持つ (ProdCsrfOverrideModule も同様)。本構想は「この実証済みパターンを汎用プラグインブリッジへ一般化する」こと。ゼロからの賭けではない。
ALPS 哲学との連続性
ブリッジ契約 (BeMart が legacy に何を要求するか) を ALPS で記述すれば、legacy EC-CUBE ランタイムは「ALPS 契約の背後にある一実装」になる — Fake と SQL が storage 契約の背後の 2 実装だったのと同型。本ブリッジは「spec が契約・実装は交換可能」の哲学の例外ではなく、もう一つの実例。
難所 (技術的チャレンジ)
- 境界契約の設計が本体の仕事。 ブリッジは EC-CUBE のイベント系を露出してはならない (腐敗が漏れる)。BeMart 側が定義するクリーンな capability interface 群でなければならない。
- ふるまいプラグイン vs 表現プラグイン。 決済・配送・業務ロジック系のブリッジはクリーン。テンプレート注入系は BeMart がテンプレートを所有した今は難しく、
#[Embed] widget でブリッジ断片を宿す形になる。
- プラグインによるコアエンティティ拡張データ。 プラグイン拡張データはブリッジ経由の extension data として露出し、BeMart のコア
final readonly Entity には入れない。
- 2 ランタイムの運用。 EC-CUBE は headless (サービスコンテナ + Doctrine + プラグインのみ、ルーティング/テンプレートは BeMart 所有) で最小化できるが、運用複雑度は上がる。
次のステップ
- これは wave ではなく 研究的アーキテクチャ initiative。
- 着手順序: 進行中の admin HTML バッチが一段落した後。
- 最初の成果物: PoC — 実プラグイン 1 つを legacy 同居・ブリッジ経由で BeMart から動かす。境界 capability interface の最小設計 + 同一 DB 同居の検証。
- 成功すれば「クリーンな核を保ちつつ EC-CUBE のプラグイン資産を継承する」道が開ける。
ステータス
研究構想。未スケジュール。PoC 着手の判断は admin HTML バッチ完了後。
設計討議から記録。関連: BEAR.Sunday 側の Form/Confirmation/CSRF 戦略の議論 (bearsunday/MyVendor.Cms#37)。
背景 — プラグイン機構のジレンマ
EC-CUBE のプラグイン機構を BeMart (BEAR.Sunday + Be Framework) へどう扱うかには、一見 2 択しかない:
final readonlyエンティティと構造的に両立しない。提案 — 第三の道: Anti-Corruption Layer による隔離
腐敗レイヤーを「除去」も「取り込み」もせず、検疫する:
final readonly/ Be Framework の純度は保たれる。なぜ実現可能か — 土台は既に 2 つ敷かれている
dtb_*/mtb_*スキーマを一切変えていない。本物の EC-CUBE 4.3 ランタイムが 同一 DB に対してそのまま走れる。「legacy を生かし続ける」の最難関＝データ乖離は、別目的 (クリーンな SQL) で下した厳密移植の決定によって既に解けている。EccubeSharedSessionAdapterが実証済みの primitive。ProdSessionOverrideModuleがSessionInterface→ EC-CUBE セッションのアダプタを既に持つ (ProdCsrfOverrideModuleも同様)。本構想は「この実証済みパターンを汎用プラグインブリッジへ一般化する」こと。ゼロからの賭けではない。ALPS 哲学との連続性
ブリッジ契約 (BeMart が legacy に何を要求するか) を ALPS で記述すれば、legacy EC-CUBE ランタイムは「ALPS 契約の背後にある一実装」になる — Fake と SQL が storage 契約の背後の 2 実装だったのと同型。本ブリッジは「spec が契約・実装は交換可能」の哲学の例外ではなく、もう一つの実例。
難所 (技術的チャレンジ)
#[Embed]widget でブリッジ断片を宿す形になる。final readonlyEntity には入れない。次のステップ
ステータス
研究構想。未スケジュール。PoC 着手の判断は admin HTML バッチ完了後。
設計討議から記録。関連: BEAR.Sunday 側の Form/Confirmation/CSRF 戦略の議論 (
bearsunday/MyVendor.Cms#37)。