Design patterns 关于设计松耦合完整系统的建议？

如何设计松散耦合的系统，这些系统可能经常需要来自彼此的数据，但不一定属于同一类别

例如，让我们进一步以旧宠物店为例，创建宠物店特许经营权。每个宠物店都有自己的网站，上面列出了他们的联系信息、促销活动和当前库存

特许经营权所有者希望在其公司网站上提供所有特许经营宠物店的列表、联系信息以及一些照片。他们希望能够更新此信息，并通过两种方式自动推送任何更新。他们还希望以自动化的方式向所有商店的网站提供促销信息

因此，在本例中，库存清单由商店“拥有”，联系信息部分由两个实体“拥有”，促销信息由总部“拥有”。由于任意原因，所有这些数据不能存储在同一个位置

---

有没有一些最佳做法或通用策略来应对这种情况？

我的理解是，这类问题通常使用一种称为“数据联合”的技术来解决——独立实体独立运作，但存在一个伞状实体，它提供了将系统视为一个整体的能力

以下是一篇可能有用的文章：

---

在规划架构时，请记住当其中一个参与者不可用时会发生什么。例如，我建议将促销信息复制到所有商店，可以作为批处理，也可以在参考数据更改时复制。这样一来，如果网络瘫痪，各个商店仍然有促销信息并且可以正常运作。

我一直在思考这个问题，我表示，类别之间的关系是由上下文决定的。任何假设类之间存在全局静态关联（固有耦合）的模型都是有问题的

我喜欢使用的另一个例子是产品

一个产品可以扮演一系列不同的角色。它与OrderItem关联，OrderItem与订单关联，OrderItem与客户关联

它是由供应商提供的

它在目录里，也许是按章节和页码

这是买方的责任，可从多个供应商处获得

轻松处理这种复杂性的能力是关系数据模型的基本优势；我还没有看到它在OOP方面得到很好的处理

旁白：还有另一个ORM（对象角色建模，请参阅VisioModeler、InfoModeler等）从关系的角度来看这个问题，非常有用（IMHO）

当您将自己与数据库的关系隔离开来时（通过使用CRUD生成器、ActiveRecords等），您就隐藏了这一重要方面。（我认为LINQ也有同样的问题，并且引入了基本的耦合问题，但我还没有完全解决。）

---

我认为如果你小心的话，你可以成功地解决这个问题，但是在设计中嵌入耦合变得很容易，特别是如果你从数据库回到应用程序的其余部分，而不是从另一个方向。

在这种情况下，SOA似乎是有帮助的。我特别指的是业务级SOA，如所述，并带有基于事件的pub-sub-async实现

您描述了几个独立所有者的业务功能：特许经营和销售。您希望实现它们之间的松散耦合

在SOA中，您定义了特许经营服务和多个销售服务实例，每个商店一个。商店最初非常相似，但可以单独发展

然后定义在这些服务中发生的共同感兴趣的业务事件。特许经营服务可以发布所有销售服务订阅的新促销活动。此事件消息包含有关促销的所有详细信息，消费者可以选择他们需要的内容。销售服务依次发布ContactDetailsChanged事件，供特许经营使用

每个服务内部都有自己的多层实现，包括数据库、面向客户的网站、与其他系统的专用集成点等

每项服务都以其认为合适的形式私自存储其感兴趣的所有数据：股票列表、联系信息、促销信息。对一个服务中信息的更新通过事件传播到其他服务

在实现方面，您需要某种服务之间的服务总线，支持通过不可靠的internet进行持久的消息传递，例如。不需要Web服务（tm）

您的服务在实现中是松散耦合的，因为它们只共享契约（它们发布的消息和端点的描述），并且可以独立地演化内部表示。它们在时间上也是松散耦合的，因为如果它们在任何时候都不互相发送同步请求，那么这些请求可能会在internet上超时。所有消息都由基础设施（服务总线）处理

---

希望这能有所帮助：）

我基本上同意上面提出的解决方案（使用SOA）。ESB可能是一种很好的方法，具体取决于应用程序的复杂性。但是，我认为ESB占用的空间很大，并且为大多数实际应用程序带来了不必要的复杂性

但是，IMHO任何好的体系结构都应该能够轻松地适应应用服务器，而无需进行重大的体系结构/设计更改

假设是基于Java的中大型n层应用程序，下面是我对中间层和EIS层的建议：

分离每个子系统实现，通过服务接口公开其功能，并隐藏直接使用或引用的实现

为每个子系统创建一个JAR（或EAR）文件，并确定运行时和编译时间