一般的なサービスに単一のプラットフォームを使用する必要がありますか、それともモジュール化する必要がありますか？
私は、同じ基本機能を持つ一連のWebアプリケーションを設計しています。つまり、ウィジェットを作成して操作する方法を全員が知っているということです。違いは、ターゲットオーディエンスと、ユーザーがウィジェットを操作する方法にあります。基本的に、これらのアプリケーションが独立して開発された場合、多くの重複した作業が発生します。
これを単純化するために、私は2つの解決策を考えました。各ソリューションの長所と短所についてのフィードバックをすべてお願いします。
「プラットフォーム」-アイデアは、独立したサービス層、つまりWebサービスがあるということです。これはWebサービスではなく、すべてのアプリケーションのバックエンドにすぎません。プラットフォームは、メッセージングまたはオブジェクトのシリアル化を介してアプリケーションと通信します。
プラットフォームをJavaで記述したいのですが、アプリケーションはRails、Django、Flex、またはJavaの何かなどの任意のWebフレームワークで記述できるようにすることを目的としています。
プラットフォームはデータベースを抽象化するため、バックエンドとのすべての対話はプラットフォームを介して行われます。これに関する潜在的な問題の1つは、プラットフォームの更新にはすべてのアプリケーションの停止が伴うことです。ただし、少なくともすべてのアプリケーションは、バックエンドに関して一貫性があります。
私はこれがどのように水平にカットされるかが好きで、アプリケーションはバックエンドをどのように編成するかを心配するのではなく、実際にはフロントエンドに焦点を合わせるだけで済みます。
「モジュール」-アイデアは、すべてをJavaで記述し、独自のjarに存在するモジュールを開発することです。各モジュールはGuiceモジュールを表し、各アプリケーションにはモジュールが含まれるだけです。彼らは望み、独自のインジェクターを作成します。
このアプローチにより、共通のデータベースを共有することを除けば、各アプリケーションは互いに完全に独立します。したがって、理論的には、プラットフォームを気にせずに、別の環境にアプリケーションをデプロイする方がはるかに簡単です。私は1つの言語環境であるJavaで立ち往生するでしょう。ただし、JRubyとJythonは利用可能です。だから多分それはそれほど問題ではありません。
また、プラットフォームに影響を与えずにアプリケーションをカスタマイズする方が簡単だと思います。 1つの欠点は、モジュールを更新する場合、そのモジュールを使用して各アプリケーションを再デプロイしたいということです。ただし、これは継続的インテグレーションを使用すれば簡単です。
お時間をいただきありがとうございます。
ゲイリーの答えに関しては、私はハイブリッドアプローチを取ることにしました。
データとサービスへのWebアプリケーションのアクセスポイントとなるプラットフォームを開発します。次に、プラットフォームをモジュール化しますが、すべてのモジュールは、親POMを持つ単一のリポジトリの下に残ります。それらすべてを単一のJARに保持することもできますが、モジュールを別のモジュールに依存させる前に、開発目的でクラスパスを分離して、他の人に考えさせたいと思います。
プラットフォーム
プラットフォームアプローチのアイデアは気に入っていますが、懸念の原因となる点がいくつかあります。
バックエンドを完全にステートレスでRESTfulにしてみませんか？ご存知のとおり、フロントエンドクライアントを駆動するために必要なJSONまたはXMLを提供するWebサービスがたくさんあります。これらのクライアントは、必要な中間表現を消費/生成できる限り、任意の言語で作成できます。最近のRESTfulWebサービスの実装は、Mavenの依存関係から離れたRESTEasyのようなJAX-RS実装では簡単です。
プラットフォームにデータベースを抽象化させることは、クライアントとサービスを可能な限り互いに独立させたいという理由だけで、良い習慣です。
プラットフォームの更新は、システム全体の停止を意味するとおっしゃいました。どうして？真剣に考えている場合は、ライブクラスターとフェイルオーバークラスターを並行して実行します。フェールオーバークラスターをアップグレードし、その上で検証テストスイートを実行して、完全にスクラッチになっていることを確認します。次に、ロードバランサーを切り替えて、ライブクラスターの代わりにフェイルオーバークラスターを使用します（ライブがフェイルオーバーになります）。プラットフォームが本当にステートレスである場合、サービスのDNSは同じままであるため、クライアントの操作は中断されません。
オブジェクトを更新する場合に発生する可能性のあるバイナリAPIの制限のために、Javaオブジェクトのシリアル化（RMIなど）を使用しないように注意します。
モジュール
モジュール間で共通のコードを共有することは、Maven（またはAntを離れることができない場合はIvy）のようなビルドシステムでは簡単です。共通のバックエンド言語を使用すると、新しい開発者の学習曲線も短縮されます。また、さまざまなバックエンドレイヤー（DAO、DTO、BOなど）で共通の機能をサポートするためのテンプレート基本クラスの大規模なコレクションがあることは間違いありません。 （これはプラットフォームアプローチにも当てはまります）。
各モジュールが分離していて互いに独立していることを考えると、開発者が効果的に通信しないと、モジュール内でコードの重複が発生する可能性があります。また、バグは1つのモジュールで修正されますが、別のモジュールでは見落とされます。これは、さまざまなクライアントの世話をするためにモジュールの複数のバリエーションを作成している場合に特に当てはまります。
明らかに、依存性注入と優れた設計はこれを軽減するのに大いに役立ちますが、プラットフォームルートを使用する場合よりもソリューションが複雑になる場合があります。