JMSの大規模な展開では、命名規則のベストプラクティスの提案は何ですか？JMSキューとトピックの命名規則に関する提案
現在、私たちはSun Developer Network Blueprintsの提案に従っています。例：
jms/<resource-name>[Queue|Topic]
私は、システム内で待ち行列とトピックがますます増えているので、これをスケーリングすることに懸念しています。私は特に階層的な命名法を使った経験や人々の命名規則の決め方について聞いてみたいと思っています。
企業グループ、アプリケーション、バージョン情報を名前空間階層に組み込むことを提案します。例えば
： JMS/mygroup.myproject.version.resource.queue
あなたが同じJMSサーバのクラスタを使用して、異なる技術的なグループを持っている場合に便利です。また、同じアプリケーションの異なるバージョン間で「クロストーク」を防止します。
私が働いていた会社は、JMS for SOAに大いに依存していました。ドメインドリブンデザインにも属していたため、ビジネスドメイン別に<ドメイン>/<ファンクション>/<バージョン>の形式でサービスを整理しました。たとえば、price/compute-foobar-maintenance-fee/1.0です。
異なるプロジェクトshouldn't have their own "version of the truth" - 2つのアプリケーションが独自の計算 - foobar-maintenance-feeサービスを持たないため、プロジェクトは名前の一部ではありませんでした。どのアプリケーションがこのサービスを提供しているかは、そのサービスに名前を付けることとは関係ありません。たぶん私のアプリケーションがサービスを提供するかもしれませんが、来年は私のアプリケーションは引退し、もう1つは引き継ぎます。契約が同じであれば、クライアントはその違いを知ってはいけません。
私はコメントが好きです（それゆえに賛成する）が、グループ/プロジェクト指向ではなく、よりサービス指向のアプローチを使用した人々の例を期待していました。 – BenM