对于较大的JMS部署，您对命名约定的最佳实践建议是什么？
目前我们正在关注Sun Developer Network Blueprints中的建议。例如：
jms/<resource-name>[Queue|Topic]
当我们在系统中获得越来越多的队列和主题时，我担心扩展它。我特别感兴趣的是听到使用分层命名的经验以及人们如何决定他们的命名约定。
答案 0 :(得分：9)
我建议将公司组，应用程序和版本信息合并到命名空间层次结构中。
例如： JMS / mygroup.myproject.version.resource.queue
如果您使用相同的jms服务器群集的不同技术组，这将非常有用。此外，它还可以防止同一应用程序的不同版本之间出现“串扰”。
答案 1 :(得分：6)
我曾经工作的公司非常依赖JMS for SOA。他们也进入了域驱动设计，因此他们按照业务领域以＆lt; domain＆gt; /＆lt; function＆gt; /＆lt; version＆gt;格式组织他们的服务。例如，price / compute-foobar-maintenance-fee / 1.0。
项目不是名称的一部分，因为不同的项目shouldn't have their own "version of the truth" - 两个应用程序没有自己的计算 - foobar-维护费服务。哪个应用程序提供服务与命名服务无关。也许我的应用程序今天提供服务，但明年，我的应用程序将退休，另一个将接管。只要合同保持不变，客户就不会/不应该知道差异。