有关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-维护费服务。 哪个应用程序提供服务与命名服务无关。 也许我的应用程序今天提供服务，但明年，我的应用程序将退休，另一个将接管。 只要合同保持不变，客户就不会/不应该知道差异。