「エンタープライズ」顧客向けのアプリケーションのフォーク
注：これは主に技術的な質問ですが、最初にビジネスの背景を説明する必要があります。
ビジネスパート
私の手には本当に興味深い状況があり、少なくとも私にとっては興味深いものです。
過去3。5年間、私は Snip Salon Software というビジネス/アプリケーションを構築してきました。美容院向けのスケジューリングソフトウェアです。重要なのは、ニーズの異なるネイルサロンや日焼けサロンとは対照的に、ヘアサロンを特にターゲットにしたことです。
このビジネスはある程度の成功を収めていますが、これまでのところ目を見張るものはありません。地元に6つのサロンがあります。
少し前に、lashサロン業界の起業家から連絡がありました。この業界では、ヘアサロンとはスケジュールのニーズが異なります。 （美容業界は驚くほど複雑な分野です！）これらの人たちは基本的に、私の製品にホワイトラベルを付けて、スタートアップのまつ毛技術者に提供する「ビジネスインボックス」タイプのパッケージの一部として販売できるようにしたいと考えています。 。
テクニカルパート
したがって、私が直面している課題は次のとおりです。
- ヘアサロンとラッシュサロンの両方に対応する1つのアプリケーションは必要ありません。すぐに悪夢に変わると思います。
- アプリケーションでほとんど同じコードを実行したくありません。それはばかげているでしょう。
そして、それは機能だけではありません-すべてのブランディングなどは、ほぼ確実にバージョンごとに異なります。
ですから、私がやりたいと思うのは、最初にコードベースをフォークし、ラッシュサロンアプリケーション用に個別のホスティングなどを設定することです。次に、時間の経過とともに、一般的な部分（予約のリマインダーメールなど）をモジュールに分解したいと思うかもしれません（RailsでRubyを使用しているので、Rails engine）次に、アプリケーションの各フォークに各モジュールの同じコピーを使用させます。もちろん、各エンジンにアプリケーションの2つのフォークに共通の機能のみが含まれるように配置します。
私の質問：技術的な観点から、この状況にどのように対処しますか？
ビジネス面でもお気軽にご参加ください。
ビジネスの観点からは、コードベースを分割し、徐々にそれらの再結合に取り組むという、可能な限り単純な方法を採用するのが正しいと思います。技術的な観点からは、コアアプリケーションを再設計して書き直すのが最善のように聞こえるかもしれませんが、絶対に確信が持てない限り、すべての作業を前もって行うことは意味がありませんラッシュプロジェクトは有益な長期的なビジネス関係になるでしょう-あなたが知っているすべての人にとって、彼らはあなたに剥がれ落ちて6ヶ月で消える可能性があります。
逆の方法で行ったでしょう。共通部分を再利用可能なライブラリにする代わりに、プラグインアーキテクチャを実装し、さまざまな種類のサルーン用のプラグインを作成する必要があります。
プラグインの共通コードベースといくつかのインフラストラクチャ（プラグインに実装されるインターフェイスなど）を含むメインアプリケーションコードがあり、プラグイン自体は異なるプロジェクトになります。また、アプリケーションと特定のプラグインのバンドルを作成できるようにする必要があります。そうすれば、ラッシュサルーンの人は、顧客が簡単にインストールできるラッシュサルーンバンドルを手に入れることができます。
共有モジュールアーキテクチャに対するプラグインアーキテクチャの主な利点は、メインアプリケーションがさまざまなモジュール\プラグインを調整するための多くの定型コードを必要とすることです。共有モジュールアーキテクチャでは、各フォークでその定型コードを複製する必要がありますが、プラグインアーキテクチャでは、メインアプリケーションで一度だけ必要です。