LHMS Framework：既存の管理機能を次の製品へ引き継ぐ

新製品を出すたびに、会員管理、資金申請の審査、コンテンツ配信、問い合わせ対応の管理画面が必要になります。これらは複数の製品で繰り返し現れ、開発の負担が積み重なっていました。

私が構築した LHMS Framework は、こうした共通要件を業務基盤にまとめ、LHMS Admin を管理画面として提供します。OTC、BT CEX、Simple、SDH などにも再利用され、新製品が引き継げる管理機能の土台になりました。

製品は違っても管理機能は重複する

当時のプロジェクトはそれぞれ独立して開発・デプロイされていました。製品固有の業務は必要でも、会員保守、配信、権限設定には似た処理が多くありました。

個別に作ると、同じ開発と結合確認を繰り返し、修正も別々に保守する必要があります。解決済みの共通課題を残し、新製品では固有業務に集中できるようにしたいと考えました。

共通基盤の範囲には制限が必要です。すべての業務ルールを集めると製品同士が依存しすぎます。一方で、ログインと権限だけでは業務開発の重複を十分に減らせません。

再利用できる管理フローを境界にしました。会員・代理店関係、コンテンツ運営、資金申請、サポートチケットは共通化し、取引の種類、注文ルール、製品特有のフローは各プロジェクトで拡張します。

例えば注文照会や入出金管理は共通でも、注文の発生・決済ルールは製品ごとに異なります。管理の入口と基礎機能を共有しつつ、個別ロジックを変更でき、独立したリリースも維持します。

LHMS Framework は ruoyi-vue-pro をもとに、JDK 17 と Spring Boot 3.x で開発しました。会員、運営、資金・注文、サポートの実際の要件に沿ってモジュールと共通機能を整理し、複数製品に再利用できる管理基盤を用意しました。

改修では既存機能の依存関係を把握する必要がありました。ログイン情報は API の認可だけでなく、操作ログや作成者・更新者の自動入力にも使われます。認証方式を変える際には、このつながりを維持しないと操作の追跡ができません。

業務機能の拡張とともに、統一したログインコンテキスト、権限検査、監査項目の自動入力を接続しました。新しいモジュールも同じ本人識別と記録を使え、会員保守や資金審査の権限境界と追跡性をそろえられます。各製品で基礎処理を作り直す負担も減らせました。

各プロジェクトが製品の範囲に応じて選択・拡張する機能です。

分野	機能・利用場面
会員・代理店	会員情報、アカウント状態、招待関係、代理店階層、顧客と担当関係の管理。
コンテンツ・通知	お知らせ、ニュース、バナー、広告、多言語コンテンツ、メールテンプレート、SMS、送信履歴。
ウォレット・資金	ウォレット、入出金申請、決済チャネル、申請詳細、承認・却下、処理履歴。
相場・取引	銘柄、価格、ローソク足、現物・契約注文の管理。各製品のルールに応じた利用と拡張。
顧客サポート	フィードバック、チャット、定型返信、チケットの受け付け・終了、問い合わせと継続対応。
運営データ	アクセス傾向、会員・資金統計、明細照会、業務記録のエクスポート。
管理・権限	担当者、役割、メニュー、操作権限、データ範囲、ログ、ファイルによる職務分担と追跡。

開発範囲には業務管理画面も含めました。LHMS Admin は既存のオープンソース管理フレームワークを拡張し、運営、審査、サポート担当者が実際に使える入口を提供します。

資金申請なら、未処理の記録から会員、金額、チャネル、状態を確認して承認または却下し、後で履歴を検索できます。運営担当はお知らせやバナーを更新し、サポート担当はチケットを受け付け、処理して終了します。役割別権限と操作記録が境界と追跡の根拠になります。

利用者向け機能と管理画面をそろえることで、業務チームが運営に必要な操作を行える状態で納品しました。

LHMS Framework と LHMS Admin は複数の派生プロジェクトで使える基盤になりました。新規プロジェクトは会員、運営、注文、サポートを引き継ぎ、自身のフローを加えられます。

製品の独立性は保てますが、共通修正を各プロジェクトへ反映する保守コストは残ります。当時解決した課題は、一度納品した管理機能を次のプロジェクトでも活用できるようにすることでした。