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

Question

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

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

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

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

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

Answer 1

我一直在思考这个问题，我说类之间的关系是由上下文决定的。而且，任何假设类之间全局静态关联(固有耦合)的模型都是有问题的。

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

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

它是由一个供应商提供的。

它在一个目录中，可能是按章节和页面。

这是买家的责任，可以从多个供应商获得。

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

旁白:还有另一种对象关系模型(对象角色建模，参见VisioModeler、InfoModeler等)。这是从关系的角度看问题，非常有用(IMHO)。

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

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

Answer 2

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

这里有一篇可能有用的文章：http://www.soamag.com/I22/0908-1.asp

在规划您的体系结构时，请记住当其中一个参与者不可用时会发生什么。例如，我建议将促销信息复制到所有商店，或者作为批处理过程，或者在参考数据发生更改时复制。这样，即使网络出现故障，单个商店仍有促销信息，并可以正常工作。

Answer 3

在这种情况下，SOA似乎很有帮助。我特别指的是业务级的面向服务的体系结构，如Bill Poole和Udi Dahan所描述的基于发布-订阅异步事件的实现。

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

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

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

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

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

在实现方面，您需要在服务之间提供某种类型的服务总线，支持在不可靠的互联网上进行持久消息传递，例如NServiceBus。不需要WebServices(tm)。

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

希望这能有所帮助:)