通販サイト/システムのリアーキテクチャは、業務フローを保ったまま内部構造をマイクロサービスやドメイン駆動設計で組み替え、契約と受注を分けて扱えるようにする再設計です。
都度購入型ECと同じ発想では、休止・スキップ・再開といった契約特有の状態変化を設計に落とし込めず、開発が長引くことがあります。
- 位置づけ：モダナイゼーションなど近接する刷新用語との違い
- 分解：契約と受注のライフサイクル
- 設計：定期購入・頒布会の状態変化を扱う条件
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・通販サイト/システムのリアーキテクチャの完全ガイド
Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
通販サイト/システムのリアーキテクチャの定義
通販サイト/システムのリアーキテクチャは、外部から見える画面や業務フローを大きく変えずに、内部のシステム構造を組み替える取り組みです。
単発の注文で完結する都度購入型ECと違い、通販・定期購入業態では契約情報と個々の受注情報を分けて管理するため、リアーキテクチャの設計も、この二層構造を前提に考える必要があります。
契約(サブスクリプション)と受注(オーダー)の分離
都度購入型のECでは、注文を受け付けてから在庫を引き当て、決済し、出荷するまでが一つの取引として完結します。一方、頒布会や定期購入では、顧客との継続的な契約(サブスクリプション)があり、その契約にもとづいて毎月や毎回の受注(オーダー)が生成される二層構造になります。
この二つを一つのモデルとして扱うと、契約の休止や解約と個別の受注処理が絡み合い、どちらか一方を変えたいだけでも、もう一方まで影響してしまう状態が生まれやすくなります。そこで、リアーキテクチャでは、契約の状態管理と受注処理を別々の責務として切り分け、それぞれを独立して変更・スケールできるように、ドメインの境界を引き直します。
モノリスの内部で密結合していたこの二つの概念は、データベースのテーブル構造だけでなく、コードの責務としても明確に分けることが、設計上の出発点になります。
深夜バッチ中心の設計の限界
多くの通販システムでは、長年の運用の中で、深夜バッチが定期購入データを読み込み、翌日分の受注をまとめて生成する処理が中心的な役割を担ってきました。
深夜バッチによる「Pull型」の仕組みは実装しやすい一方で、バッチが完了するまで状況を確認できず、スキップや休止の反映にも翌営業日までの時間差が生じるという制約があります。
リアーキテクチャに着手する前に、この深夜バッチがどれだけ複雑な条件分岐を抱えているかを洗い出す必要があります。たとえば、頒布会の周期変更、同梱物の出し分け、特売期間中の例外処理などが一本のバッチ処理に積み重なっている場合、そのロジックをドメインごとに解きほぐすだけでも数週間から1.5か月程度を要することが一般的です。
隣接するシステム刷新の考え方との違い
通販サイト/システムの刷新では、モダナイゼーションやシステム刷新、システム更改、リニューアルといった近い言葉が使われることがあります。それぞれ主眼を置く観点が異なるため、リアーキテクチャがどの部分を担うのかを押さえておくと、社内でプロジェクトの位置づけを説明する際に役立ちます。
モダナイゼーション・刷新・更改・リニューアルとの違い
通販サイト/システムのモダナイゼーションは、自社に合う進め方を選ぶ、HOW(どう進めるか)の総論にあたります。進め方の手法には、リホストやリプラットフォーム、リファクタリングのほか、リビルドやリプレースもあります。ほかの近い言葉は、それぞれ主眼が異なります。
- システム刷新：会員基盤や受注実績という資産価値を根拠に投資判断を行う、WHY・WHENの経営判断が主眼です。
- システム更改：決済代行の旧APIやOS・ミドルウェアのサポート終了といった外圧型のトリガーを起点にした契約・調達の話です。
- リニューアル：マイページの使い勝手や同梱チラシのデザインといったUX・UI起点の改善を指すことが多くなります。
これに対して通販サイト/システムのリアーキテクチャは、選んだ進め方(モダナイゼーションの一手法)を技術的にどう実装するか、つまりアーキテクチャそのものの再設計に踏み込む領域です。経営判断や契約更改のタイミングと並行して、内部構造をどう組み替えるかという技術的な設計論点を扱います。
ECリアーキテクチャとの違い
ECリアーキテクチャという言葉は、都度購入型の一般的なECサイトを対象にした取り組みを指すことが多いです。
- 技術の中心：ヘッドレスコマースやMACHアーキテクチャといった技術で、カート・決済・在庫・検索という共通ドメインを刷新します。
- 処理の流れ：都度購入は「注文→在庫引当→決済→出荷」という単発の処理(Saga)で完結するため、設計上の主な関心は各処理の疎結合化やAPI化に置かれます。
- 構造：通販・定期購入業態では、契約と受注のライフサイクルが分離しているという違いがあります。
- 固有の論点：休止・スキップ・再開という、契約期間中に恒常的に発生する状態変化を、補償トランザクションを含めてどう設計するかが課題になります。
都度購入型ECの技術知見は、そのまま適用するのではなく、頒布会や同梱物選定という通販特有の業務ロジックを、どのドメインに配置するかを個別に検討する必要があります。
リアーキテクチャを支える技術的な仕組み
通販サイト/システムのリアーキテクチャでは、モノリスとして一体化していた機能を、ドメインごとの境界に沿って分解し、必要に応じてマイクロサービス化します。どこで機能を分割するかは、ドメイン駆動設計(DDD)の考え方で決めます。また、処理をどう伝播させるかはイベント駆動の設計で決まり、この二つが技術的な仕組みの中心になります。
ドメイン駆動設計による境界の引き直し
ドメイン駆動設計では、業務領域を「コアドメイン」と「汎用サブドメイン」に分類し、どこに自社独自の価値があるかを明確にします。通販・定期購入業態では、同梱物の選定ロジックや頒布会・スキップ制御のように、自社の商品構成や顧客対応方針に強く依存する領域がコアドメインにあたります。
一方、決済処理や定期課金の管理といった、業種を問わず共通する処理は汎用サブドメインに位置づけられます。この分類を先に行わずにマイクロサービス化を進めると、本来独立してよいはずの機能同士が暗黙のうちに依存し合う「分散モノリス」に陥ります。そうなると、サービスを分けたメリットである独立デプロイやスケーリングの自由度を失ってしまいます。
境界の引き方を誤らないためには、既存のバッチ処理やコードを机上で分けるより、実際の業務フローに沿って、どのイベントが誰の責務で発生するかを洗い出すことが欠かせません。
Pull型からPush型のイベント駆動への切り替え
モノリス時代の深夜バッチによる「Pull型」の処理を、イベントが発生するたびに後続処理へ伝播させる「Push型」のイベント駆動へ切り替えるかどうかは、リアーキテクチャにおける大きな設計判断の一つです。
Push型に切り替えると、スキップや休止の反映がほぼリアルタイムになります。一方で、イベントの順序保証や重複配信への対処など、Pull型では意識する必要がなかった課題に向き合うことになります。
すべての処理を一律にPush型化する必要はありません。即時性が求められる処理と、数分から数時間程度の遅延が許容できる処理を区別し、どちらの方式を採用するかをドメインごとに判断するのが現実的です。この判断を誤ると、本来コストを抑えられるはずの処理にまで高価なイベント基盤を適用することになり、運用コストだけが増えてしまいます。
定期購入・頒布会に特有の設計論点
通販サイト/システムのリアーキテクチャで技術的な難易度が最も高いのは、契約期間中に恒常的に発生する状態変化と、頒布会・同梱物という自社独自の業務ロジックを、分散システムの中にどう位置づけるかという論点です。
定期便のスキップ・休止・再開とSagaパターン
定期便のスキップ・休止・再開という操作は、決済、在庫、配送手配など複数のサービスにまたがる処理を、途中で取り消したりやり直したりする必要があるため、一般的な都度購入の注文処理より複雑です。こうした分散トランザクションには、各サービスが自分の処理を実行した後、失敗が起きた場合に「補償トランザクション」で処理を打ち消していくSagaパターンが用いられます。
たとえば、休止を申し込んだ後に決済の取り消しは成功したものの、すでに出荷準備が進んでいた在庫の解放が間に合わないケースがあります。こうした場合は、どちらの処理を先に確定させ、どちらを補償対象にするかをあらかじめ設計しておく必要があります。
同じ休止処理が連続してクリックされた場合にも、二重に取り消し処理が走らないよう、冪等性(同じ処理を何度実行しても結果が変わらない性質)を担保する仕組みも欠かせません。
頒布会・同梱物選定ロジックの置き場所
頒布会や同梱物の選定ロジックは、購買履歴や継続回数にもとづいて内容を決めるため、レコメンドエンジンに近い複雑さを持ちます。加えて、自社の商品戦略や販促方針が色濃く表れるコアドメインです。
この処理をどのサービスの責務として実装するかを誤ると、本来独立させたかった注文処理や決済処理と結び付いてしまいます。その結果、機能追加のたびに関係のないサービスまで改修が必要になる「分散モノリス」の状態を招きます。
同梱物選定エンジンが停止した場合に、チェックアウトや決済まで巻き込まれて注文が完了できなくなる事態を避けるため、障害分離の設計も欠かせません。同梱物選定でエラーが起きても、あらかじめ定めたデフォルトの同梱内容で注文を続けられるようフォールバックを用意しておけば、コアドメインの複雑さが基幹の購入処理の安定性を損なわずに済みます。
段階移行を支える主要な仕組み
通販サイト/システムのリアーキテクチャは、一度にすべてを作り替えるより、既存システムを稼働させたまま特定の機能から段階的に移行していく進め方が一般的です。
段階移行を技術的に支えるのは、API Gatewayを使ったストラングラーフィグパターンと、コールセンターなど既存業務との連携APIです。
ストラングラーフィグパターンによる段階的な置き換え
ストラングラーフィグパターンでは、既存のモノリスの前段にAPI Gatewayを配置します。リクエストの一部を新しいマイクロサービスへ、残りをそのまま既存システムへ振り分けることで、システム全体を止めずに機能を少しずつ新しい構造へ移し替えていく進め方です。
名称は、他の樹木に絡みついて徐々に取って代わる植物に由来しています。つまり、一気に置き換えるより、既存システムを残したまま新旧が共存する期間を計画的に設けることが特徴です。
通販・定期購入業態のリアーキテクチャでは、まずコールセンター連携用のAPIなど、特定のトラフィックだけを新しいサービスへ振り分けるところから始めることが多いです。そのため、影響範囲を絞りながら実際の本番トラフィックで検証できるという利点があります。
コールセンター電話受注連携のAPI-first設計
通販・定期購入業態では、電話によるコールセンター受注が一定の比率を占める企業が多く、この経路をどうシステムに組み込むかもリアーキテクチャの重要な論点です。API-first設計は、実装より先にAPIの仕様(DTOの構造など)を確定させる進め方です。
API-first設計で並行開発を進めるときは、開発の順序だけでなく、電話とWebで同じ在庫を扱う点も論点になります。
- 開発の進め方：バックエンドの完成を待たずにフロント側やコールセンターシステムの改修を並行して進められ、実装の複雑度を中程度に抑えられます。
- 並行する受注：オペレーターが電話で在庫を確保している最中に、同じ商品がWebサイトから購入されるといった競合が起こり得ます。
- 設計の要点：競合に備えて、楽観的ロックなど在庫確保の排他制御もあわせて設計する必要があります。
- 放置時の影響：在庫の同時アクセスという論点を見落とすと、想定外の二重販売につながります。
導入目的と期待できる効果
通販サイト/システムのリアーキテクチャに取り組む目的は、負荷が集中する処理だけを独立してスケールできるようにし、機能追加のたびにシステム全体を止めずに改修できる状態を作ることにあります。見た目を刷新することが目的ではありません。
高負荷機能の独立したスケール
通販・定期購入業態には、月末の定期受注確定日やセール時期に、トラフィックとバッチ処理が極端に集中するという特性があります。そこで、同梱物・頒布会最適化のように高いCPU負荷を要するロジックを独立したサービスに切り出しておけば、その処理だけを需要に応じてスケールさせられます。そのため、システム全体を一律に増強するより、無駄なリソースを抑えられます。
機能を細かく分割するほど、サービス間の通信や監視、デプロイの管理といった運用オーバーヘッド(いわゆるマイクロサービス税)も増えていきます。
すべてを細分化すると、スケーラビリティ以上に運用の複雑さが増すため、どこを独立させる価値があるかを、負荷が集中する処理から見極めることが前提になります。
改修のスピードとコンプライアンス対応の両立
改修のスピードとコンプライアンス対応を両立させるには、次の点が論点になります。
- 対象の限定：PCI-DSSなどへの対応が求められる定期便請求(サブスクリプション課金)を独立させると、監査対象を限定でき、周辺機能への影響も抑えられます。
- SaaSの活用：決済や定期課金といった汎用サブドメインを外部のSaaSに委譲する構成も、監査範囲の限定という観点から選ばれることがあります。
- 連携側の改修：コールセンター連携やフロントの改修を、バックエンドの完成を待たずに並行して進められる体制が整うと、業務側の追加要望に段階的に対応しやすくなります。
- データの管理主体：独立したサービスが増えるほど、どのサービスがどのデータの正本かを管理する体制も必要になります。
- 技術以外の要素：リアーキテクチャの効果は、技術的な設計だけでなく運用体制の整備とあわせて評価する必要があります。
通販サイト/システムのリアーキテクチャ導入前に確認しておきたいポイント
通販サイト/システムのリアーキテクチャは効果の大きい取り組みです。ただし、組織の規模や既存システムの状態によっては、マイクロサービス化以外の選択肢のほうが現実的な場合もあります。導入前に確認しておきたい論点は、組織の規模に合う構成を選べるか、既存バッチの複雑さを把握できているか、運用を担うSRE人材がいるかです。
組織規模によるモジュラーモノリスの選択肢
エンジニアチームの人数がおおむね10〜15名に満たない組織では、マイクロサービス化で増える運用・監視・デプロイ管理の負荷が、独立したスケーリングで得られるメリットを上回ることがあります。
エンジニアチームの人数が限られる組織では、内部の責務は明確に分けつつ、デプロイ単位は一つにまとめる「モジュラーモノリス」に留めておくことが、無理なく運用できる現実的な選択になります。
既存の深夜バッチの複雑度の洗い出し
長年蓄積された定期購入バッチが、頒布会の周期変更や特売期間の例外処理をどれだけ抱えているかによって、ドメイン分析・境界設計に必要な期間は大きく変わります。
着手前にこのバッチのロジックを洗い出さないまま一括で移行計画を立てると、想定していなかった例外処理が後から見つかり、スケジュールの見直しが繰り返される原因になります。
Sagaパターンを維持するためのSREスキルの有無
補償トランザクションを含むSagaパターンは、実装した後も、決済は成功したのに在庫が確保できず出荷が失敗するといった例外ケースに、継続して対応する運用体制を必要とします。
Sagaパターンの運用を担えるSRE人材が社内に不足している場合は、外部の専門チームと連携する体制をあらかじめ検討しておくことが望まれます。
最初に着手する範囲の絞り込み
すべてのドメインを同時にマイクロサービス化しようとすると、検証すべき分散トランザクションの組み合わせが膨大になります。その結果、プロジェクト全体の見通しが立てにくくなります。
そこで有効なのが、定期便のスキップ処理とコールセンター連携の一部など、影響範囲を絞った垂直スライスから着手する進め方です。通販・定期購入業態のリアーキテクチャでは、実際の運用で得られた知見を踏まえながら、対象を広げていきます。
まとめ
通販サイト/システムのリアーキテクチャは、都度購入型ECの技術知見をそのまま流用するのではなく、契約(サブスクリプション)と受注(オーダー)のライフサイクルが分離した通販・定期購入業態の構造を前提に進めます。ドメイン駆動設計と、Sagaパターンによる補償トランザクションで内部構造を組み替える取り組みです。
同梱物選定や頒布会制御という自社のコアドメインをどう境界設計するか、決済や定期課金という汎用サブドメインをどこまで外部のSaaSに委譲するかを見極めることが、成否を分ける重要な論点になります。
段階移行と組織体制の計画
ストラングラーフィグパターンによる段階移行は、既存システムを止めずに新しい構造へ移れる有効な手段です。ただし、Sagaパターンの運用を支えるSREスキルや、エンジニアチームの規模に見合った移行範囲の設定とあわせて計画する必要があります。
一括で刷新を進めるより、影響範囲を絞った垂直スライスから着手し、検証を重ねながら対象を広げていくほうが、通販・定期購入業態特有の複雑さに対応する現実的な進め方です。
既製の枠組みで対応しきれない業務要件へのフルスクラッチ支援
決済や定期課金のような汎用的な処理は、外部のSaaSに任せられます。一方で、頒布会・同梱物選定・スキップ制御といった自社独自の業務ロジックは、既製のパッケージだけでは十分に表現しきれないことが少なくありません。
riplaはフルスクラッチ開発の立場から、こうしたコアドメインのドメイン分析・境界設計や、既存の基幹システム・コールセンターシステムとの連携を含む構築を支援しています。具体的な選定の進め方は通販サイト/システムのリアーキテクチャの選定ポイント/選び方/種類で解説しています。
▼全体ガイドの記事
・通販サイト/システムのリアーキテクチャの完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。