针对较大的JMS部署，您有什么关于命名约定的最佳实践建议吗？
目前，我们正在遵循Sun Developer Network Blueprints中的建议。例如：
jms/<resource-name>[Queue|Topic]
随着系统中队列和主题的增多，我担心扩展性的问题。我特别想了解使用分层命名的经验以及人们如何决定他们的命名约定。
2个回答
10
我曾经工作的一家公司非常依赖JMS实现SOA。他们也使用领域驱动设计，因此按业务领域组织服务，格式为<domain>/<function>/<version>。例如，price/compute-foobar-maintenance-fee/1.0。
项目名称不是名称的一部分，因为不同的项目不应该有自己的“真相版本” - 两个应用程序不会有自己的compute-foobar-maintenance-fee服务。哪个应用程序提供服务与命名服务无关。也许我的应用程序今天提供服务，但明年，我的应用程序将被淘汰，另一个应用程序将接管。只要合同保持不变，客户端就不会/不应该知道区别。
- spaaarky21
9
我建议将公司组、应用程序和版本信息结合到命名空间层次结构中。
例如：jms/mygroup.myproject.version.resource.queue 如果您有不同的技术组使用相同的jms服务器集群，这是非常有用的。此外，它还可以防止同一应用程序的不同版本之间的“交叉对话”。
例如：jms/mygroup.myproject.version.resource.queue 如果您有不同的技术组使用相同的jms服务器集群，这是非常有用的。此外，它还可以防止同一应用程序的不同版本之间的“交叉对话”。
- Dave Jefferson
1
我喜欢这个评论（因此点了赞），但我希望看到更多使用面向服务的方法而不是面向组/项目的人的例子。 - BenM
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接