1. イントロダクション:マッチングサイト乱立時代の「車輪の再発明」を止める
「新しいマッチングサービスを立ち上げる」――その決断のたびに、私たちは似たような機能をゼロから作り直してはいないでしょうか。
求人サイト、スキルシェア、B2Bの商談プラットフォーム。一見するとこれらは全く異なるビジネス領域に見えます。しかし、その背後に流れるデータの「美学」を抽象化してみれば、そこには「募集(Listing)があり、応募(Application)があり、合意を経てマッチ(Match)が成立する」という、驚くほど共通した構造が存在することに気づきます。
この共通構造を解明せず、場当たり的な開発を繰り返すことは、エンジニアリングにおける「美」の欠如であり、ビジネスの機動力を削ぐ最大の要因です。本記事では、LaravelとMySQLを軸に据え、複雑な「つながり」を1つの方程式に落とし込むことで、圧倒的な再利用性を実現するモダン・アーキテクチャの神髄を紐解きます。
2. 「Core」と「Domain」の完全分離:エンジンの汎用性を極める
優れた設計の根幹は、システムの心臓部である「不変のロジック」と、サービスごとに変化する「固有のルール」を峻別することにあります。今回のアーキテクチャ方針が掲げるのは、「Core Matching Engine」と「Domain Layer」の完全分離です。
- Core Matching Engineの責務: ユーザー認証、プロフィール管理、募集・応募のライフサイクル、決定論的な状態遷移、検索基盤といった、マッチングサービスとしての普遍的な機能を担います。
- Domain Layerの責務: 求人、スキルシェア、Datingといった各ドメイン特有の入力項目、バリデーション、表示ロジックを担います。
ソースコードの設計原則にある「Core と Domain を分離する」という思想は、単なる整理整頓ではありません。Coreを疎結合な「ブラックボックス」として独立させることで、将来的にBladeベースのUIを維持したまま、バックエンドをRESTやGraphQLといったAPIとして切り出す際にも、ドメイン固有のルールを壊すことなく進化させることが可能になります。この境界線の確立こそが、技術的なエレガンスとビジネスの拡張性を両立させる鍵となります。
3. メタデータとテンプレート:テーブルを汚さずに「個性」を宿す
サービスを横展開する際、最大の障壁となるのは「データベースの硬直化」です。求人サイトなら「給与」、スキルシェアなら「対応形式」といった具合に、サービス固有のカラムを共通テーブルに追加し続ける行為は、データベースを瞬く間にメンテナンス不能な廃墟へと変えてしまいます。
この課題に対する解法が、JSON形式のmetadataカラムとテンプレートシステムの融合です。
コアテーブル(listingsやprofilesなど)にはタイトルや説明といった最小限の共通項目のみを配置し、サービス固有の項目はすべてmetadataへ格納します。そして、そのデータの振る舞いを「テンプレート定義」で制御します。
この設計の驚異的な点は、以下の要素を「開発者の手を離れた運用」で制御できる点にあります。
- 動的バリデーション: テンプレート定義に基づき、ドメインごとに異なる必須チェックや型チェックを動的に構築します。
- 柔軟な検索演算子:
exact(完全一致)、contains(部分一致)、between(範囲検索)といった演算子をテンプレート側で指定することで、SQLを一行も書き換えることなく「最低給与での絞り込み」や「キーワード検索」を自在に操ることが可能になります。
4. 美しき状態遷移:一方向マッチングを支える「不変のルール」
複雑になりがちなマッチングフローをシンプルに保つのは、厳格かつ決定論的な状態遷移の設計です。本基盤では、主要な3つのエンティティに対して、迷いのない一方向のパスを定義しています。
- Listing(募集):
draft(下書き) ->open(公開中) ->closed(終了) - Application(応募):
pending(保留) ->accepted(承認) /rejected(却下) - Match(成立):
active(有効) ->closed(終了)
ここで最も重要な「設計の掟」は、**「Applicationがacceptedになった瞬間にのみMatchを生成する」**というルールです。
この整合性を守るのが、ビジネスロジックの守護者たる「Service層」の役割です。Controllerによる安易な文字列更新を厳禁し、状態更新をService層に集約することで、データベースが不正な状態に陥ることを防ぎます。承認という「決定論的イベント」を起点にMatchが生成されるこのフローこそが、システム全体の信頼性を担保する不変のルールとなります。
5. 1つのコードベース、2つの世界:マルチサイト展開の魔法
「1つのコードベースで、求人サイトとスキルシェアサイトを同時に、かつ独立して運用する」。これは理想論ではなく、構成の最適化によって実現される現実です。
本アーキテクチャでは、環境変数(.env)で定義されたMATCHING_SITE_CODEがconfig/matching.phpを駆動し、同一のLaravel基盤上で全く異なる顔を持つサイトを起動させます。ここで重要なのは、見かけ上の違いだけでなく、**徹底した「隔離」**です。
- DB・セッションの完全分離: 同一のVPS上であっても、ドメインごとにデータベース名とセッションCookie名を完全に分離します。これにより、求人サイトのユーザーがスキルシェアサイトに混入するような事故を構造的に排除します。
- ルールセットとしてのサービス: 「サービスとは、同一基盤上で動くルールセットである」というソースの思想に基づき、ブランド名、ロゴ、使用テンプレートを切り替えることで、インフラコストを最小限に抑えつつ、マルチドメイン展開を可能にします。
6. 結論:抽象化の先にある「未来」
優れた設計とは、単に「今必要なものを作る」ことではありません。それは、「未来の変更を、構造を壊さずに受け入れる器を作る」ことです。
今回ご紹介した設計は、マッチングという営みを「募集・応募・承認」という極限まで抽象化されたプロセスとして捉え直し、「Core + Metadata(Domain) = Equation(方程式)」として結実させたものです。この揺るぎない基盤があるからこそ、その上に載せるドメインは自由で多様な個性を放つことができます。
技術の表面的なトレンドを追いかけるのではなく、その背後にある構造の美学を追求すること。それこそが、エンジニアリングにおける真の再利用戦略であり、「Engineering Beauty(エンジニアリングの美)」の体現です。
あなたが次に作るサービスは、また「ゼロ」から始めますか? それとも、この揺るぎない「基盤」の上に、新しい未来を築きますか?