3

私は、顧客がアーティストポートフォリオのWebサイトを管理できるようにするRailsアプリケーションの主要な開発者です。システムに伴う4つの非常に異なるタイプの動作があります。

  • ログインしたユーザーがポートフォリオのコンテンツを管理できるようにする管理者の動作
  • ポートフォリオ表示動作。これにより、ユーザーのポートフォリオが一般の訪問者に表示されます。
  • コンバージョンファネルの動作。サービスに関する情報を表示し、新規ユーザーに登録を促します
  • スーパー管理者の動作。他の3つの動作に関する統計をサービス所有者に表示します

現在、これらの4つの動作セットは名前空間付きコントローラーに分割されていますが、すべて同じモデルを共有しています。システムの4つの部分は実質的に動作を共有しないので、アプリケーションを4つの別々のアプリケーションまたはエンジンに分割する（そして共有される動作をgemに抽出する）ことにメリットがあるかどうか疑問に思います。

例として、ユーザー統計を処理するシステムの部分は、ポートフォリオへのYouTube埋め込みのレンダリングについて「知る」必要はありません。ポートフォリオの表示を処理するシステムの部分は、A/Bを「知る」必要はありません。テスト、および新規ユーザーのサインアップを処理するシステムの部分は、新規ユーザーのサインアップ以外に他の多くのことを「知る」必要はありません。

さらに、私が対処したい特定の問題は、経験の浅いチームメンバーが、新しいユーザーのサインアップを扱うサイトの部分に少しのコードを提供できるようにしたいということです。サイトのその部分で1つか2つのバグが本番環境にプッシュされたとしても、世界の終わりにはなりませんが、ユーザーのポートフォリオを表示するシステムの一部で本番環境のバグを許可しないことが非常に重要です。

では、コードベースの保守性と読みやすさの観点から、これら4つのコンポーネントを別々のアプリケーションに分離することは理にかなっていますか？そうすることで、複雑さを排除することなく、システムの別のレイヤーに複雑さを押し込むことがどの程度必要になるでしょうか。このタイプの分離は、より明確に分離されたクラスとモジュールを作成することによって、より適切に達成されますか？

どうもありがとう！

4

1 に答える 1

2

半独立エンジンは、サイロ コード作業を許可するという目標を達成し、スタイルシートなどのすべてのリソースを簡単に共有できます (提供するサービスは 1 つであるため、これはおそらく重要です)。

マウント可能なエンジンでも目的は達成できますが、共有はより困難です。

API を 1 つ以上のフロントエンド アプリに提供する機能指向のアプリを多数備えたサービス指向のアーキテクチャが機能する場合があります。前もってより多くの作業が必要になりますが、時間の経過とともにサービス全体がより複雑になることがわかった場合、長期的に見れば報われる可能性があります。

楽しい選択！

于 2012-06-22T04:34:07.043 に答える