いくつかのサービス間でデータレイヤを共有するためのPlayフレームワークモジュールの構築

Question

SOAの概念を念頭に置いて、私は同じデータモデルを活用するいくつかの異なるサービスを提供することを意図しています。ポーカーアプリケーションを想像して - 私たちは以下のサービスを持っていることがあります。

• ゲームのフロントエンド
• 管理フロントエンド
• プレイヤーランク/リーダーボードサービス
• プレーヤーは、サービス
• 銀行統合サービス
• 資金を調達。.. 。

これらのサービスはすべて、同じモデルを使用してください（おそらく、必要な場所に追加のモデル情報を提供しているかもしれません）。

Play！私がこのデータモデルを外部化することは可能ですが、Playを使用することで得られる利益を維持しています。たとえば、実行時の再コンパイルなどです。

モジュールは仕事に役立つかもしれないようですが、それらに関するドキュメンテーションはほとんどなく、反対のパラダイムが示唆されています。サービスはモジュールであり、コアプレイアプリケーションは機能を引き出します。

ガイダンスをいただければ幸いです。

Answer 1

Playを使用して真のSOAスタイルを得るのは難しいです。 Playは単なるフレームワークではないため、HTTPRequestからデータベースの永続性にいたるまで、孤立していないサービスを提供するWebプラットフォームです。

実際にデータを外部化する必要がある場合は、Spring moduleをお試しください。 Springは永続性、ビジネスロジックを処理し、これをサービスインターフェイスにカプセル化する必要があります。

Playアプリでは、コントローラはこれらの公開されたサービスインターフェイスに依存します。 SpringのサービスはPlayの機能に依存している必要があります（検証やJPA永続性などのためにはインポートなどはありません）

目的は - tommoです（必要な場合は、MVCフレームワーク（Spring MVC、 Strutsなど）と同じサービスを利用します。

Answer 2

私は似たような試みをしています。私がしようとすることを約午前何

はモジュール

で

• 書き込みDALは、独立したモジュールとして、それぞれ別々の構成要素を記述しています。
• 今後、各コンポーネントを別のアプリでホストすることができます。アプリを移動し、DALモジュールをインストールすれば、すべて設定されます。これはうまくいけばスケーラビリティのものをカバーします。

理論的に私は、Eclipseでビルドコマンドを設定することでプレイコマンドを呼び出すことができます。これにより、メインアプリケーション用のモジュールを自動的にビルドできるようになります。

これは私にとってはうまくいくでしょう...