有關JMS隊列和主題命名約定的建議

Question

對於較大的JMS部署，您對命名約定的最佳實踐建議是什么？

目前，我們正在遵循Sun Developer Network Blueprints中的建議。 例如：

jms/<resource-name>[Queue|Topic]

隨着我們在系統中獲得越來越多的隊列和主題，我擔心擴展它。 我特別感興趣的是聽到使用分層命名的經驗以及人們如何決定他們的命名約定。

Answer 1

我建議將公司組，應用程序和版本信息合並到命名空間層次結構中。

例如：jms / mygroup.myproject.version.resource.queue

如果您使用相同的jms服務器群集的不同技術組，這將非常有用。 它還可以防止同一應用程序的不同版本之間出現“串擾”。

Answer 2

我曾經工作的公司非常依賴JMS for SOA。 他們也進入了域驅動設計，因此他們按照<domain> / <function> / <version>格式按業務域組織服務。 例如，price / compute-foobar-maintenance-fee / 1.0。

該項目不是名稱的一部分，因為不同的項目不應該有自己的“真相版本” - 兩個應用程序不會有自己的計算 - foobar-維護費服務。 哪個應用程序提供服務與命名服務無關。 也許我的應用程序今天提供服務，但明年，我的應用程序將退休，另一個將接管。 只要合同保持不變，客戶就不會/不應該知道差異。