Jack Van Hoof 撰写了一篇关于如何建模联邦服务总线基础设施的说明指南，这种基础设施给企业中与之交互的各部分提供了预期的自治水平。在他看来，ESB 一词并未对它服务的范围着墨太多，因此他进一步在它们联邦的基础之上对 ESB 进行了分类。
这个模式在一个由多个逻辑总线组成的联邦服务总线基础设施中划出了 4 个关注级别：
- 应用级：应用级服务总线支持细粒度的应用级流程和活动监视。每个应用绑定到它自己的逻辑总线上。在实践中，这种边界一般是通过应用服务器上的应用名字空间来实现的，Java 使用的是 JMS，.net 则是 WCF。
- 领域级：领域是一个功能内聚的实体，如人力资源管理、财务、物流、销售、收购。这一级别的服务支持在这个特别领域内跨应用的流程和活动监视。领域同样会暴露由领域应用访问的领域通用服务。如果存在多个服务总线，每个领域一个。
- 公司（企业）级：公司级服务总线支持跨领域的流程和活动监视。在公司级，一个公司总线为一个企业服务，领域同样可以访问这个企业。
- 外部级：外部级服务总线支持与公司外部世界、业务合作方、消费者和供应商的交互。
由于这种总线分类法很自然地在企业内总线类型中形成了一个层次结构，因此他警告说，如果没有对它进行有效地建模，它最终很可能会变成一种被他称为是“意大利面条”的结构。为了避免这种情况的发生，他对拓扑和服务总线范围的建模使用了“父 - 子”隐喻。
在这个模式中，提倡使用层次化的交互结构来维护所期望的自治边界和结构可控性。这种层次化的结构最终导致了一种层次化的“父 - 子”通信方法。一个子只有一个父（各位，这只是个比方），一个父可能有多个子。例如，一个应用是一个领域的子（n:1）；一个领域是多个应用的父（1:n）。
在解释完这之后，他推荐按照以下规则来避免出现“意大利面条式”的结果：
- 子级流程可以向它的父级总线发送消息
- 父级流程可以向它的子级总线发送消息
- 向下的跨级消息传递总是由父级总线依次传递给子级总线
- 向上的跨级消息传递总是由子级总线依次传递给父级总线
- 父级总线可以向它的子级总线暴露服务
他还提到了实践中的一些注意事项，它可不像只是遵循这些规则一样那么简单。
- 行政方面的考虑 > 领域模型成形的基础主要是自治团体，后者源于文化、历史和权力。领域往往有权自行决定像应用、工具和平台这类的资源。
- 互操作性方面的考虑 > 关于联邦服务总线基础设施，使用不同产品 [……以及] 支持 [它们间的] 互操作性是当前 IT 业的焦点。
Jack 给出了一种服务总线基础设施的建模方法。关于详细内容请阅读原文。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
深度融合大规模敏捷与 DevOps，攻克保险领域 ToB 质量保障的三大难题
从“全干”工程师的发展路径，看前端的定位与价值
DevChat：从实践中来到实践中去的 GPT 智能编程工具设计
评论