如何设计松散耦合的系统，这些松耦合的系统通常可能需要来自彼此的数据，但不一定属于同一类别？关于设计松耦合完整系统的建议？
例如，让旧的Pet-shop示例更进一步，并创建宠物店专营权。每家宠物商店都有自己的网站，列出他们的联系信息，促销活动和当前库存。
特许经营店主想要列出所有特许宠物店以及联系信息，并可能在其公司网站上提供一些照片。他们希望能够更新这些信息，并且可以自动双向推送任何更新。他们还希望以自动方式向所有商店的网站提供促销信息。
因此，在这种情况下，库存清单由商店“拥有”，联系信息由两个实体“部分拥有”，并且促销信息由总部“拥有”。由于任意原因，所有这些数据不能存储在同一个地方。
是否有一些最佳实践或常见策略来应对这种情况？
我一直在思考这个问题，并且我表达了类之间的关系是上下文确定的。任何假定全局静态关联（固有耦合）的模型都是有问题的。
我喜欢使用的另一个示例是Products。
产品可以扮演一大堆不同的角色。它与OrderItem相关联，OrderItem与与客户关联的订单相关联。
它由供应商提供。
它在目录中，也许按章节和页。
这是买方的责任，有多个供应商提供。
处理这种复杂性的能力很容易就是关系数据模型的根本好处;而且我还没有看到它在面向对象方面的处理。
另外：还有另一个ORM（对象角色建模，参见VisioModeler，InfoModeler等），它非常有用地查看关系方面的问题（恕我直言）。
当你将自己与数据库的关系性隔离（通过使用CRUD生成器，ActiveRecords等）时，你隐藏了这一重要方面。（我认为LINQ有同样的问题，以及引入基本的耦合问题，但我还没有完全解决它）
我认为你可以成功地通过它的方式，如果你小心，但是在设计中嵌入耦合变得很容易，特别是当你从数据库返回到应用程序的其余部分时，而不是其他方向时。
我的理解是，这种问题通常是使用称为“数据联邦”的技术来解决的 - 独立实体独立运作，但存在一个伞状实体，提供将系统视为整个。
这里有一篇文章，可能是有用的： http://www.soamag.com/I22/0908-1.asp
在规划架构，记住，当参与者之一是不可用会发生什么。例如，我会建议将促销信息复制到所有商店，无论是作为批处理进程还是参考数据更改时。这样，如果网络出现故障，各个商店仍然有促销信息并可以运作。
看来SOA在这种情况下可能会有帮助。我特指具有业务级别的SOA，如Bill Poole和Udi Dahan带有pub-sub异步事件的实现。
您描述了几个业务职能与单独的所有者：特许经营和销售。你想要实现它们之间的松散耦合。
在SOA方式中，您定义了特许经营服务以及多个销售服务实例，每个商店都有一个实例。商店最初非常相似，但可以分开进化。
然后定义这些服务中发生的共同感兴趣的商业事件。特许经营服务可以发布所有销售服务订阅的NewPromotion事件。此事件消息包含有关促销的所有详细信息，消费者会选择他们需要的内容销售服务轮流发布ContactDetailsChanged事件以供特许经营使用。
每个服务都有在里面自己的多层次的实现，完成与数据库，面向客户的网站，与其他系统等
每个服务店私下一切感兴趣的私人数据集成点：库存清单，联系信息，促销信息 - 以它认为合适的形式。一项服务中的信息更新通过事件传播到其他服务。
在实现方面，您需要某种服务之间的服务总线，支持不可靠的互联网上的持久消息，例如， NServiceBus。没有必要的WebServices（TM）。
您的服务在实现中松散耦合，因为它们只共享合同（它们发布的消息和端点的描述），并且可以独立演化内部表示。它们也是及时松散耦合的，因为如果它们在任何时候都不会互相发送可以通过互联网超时的同步请求。所有消息都由基础设施（服务总线）处理。
希望这会有所帮助:)
我主要同意上面提出的解决方案（使用SOA）。取决于应用程序的复杂性，ESB可能是一个好方法。但是，我认为ESB占用的空间很大，并且为大多数真实世界的应用程序带来了不必要的复杂性。
但是，恕我直言，任何好的架构应该很容易适应应用程序服务器，无需进行重大的架构/设计更改。
假设一个基于Java的中大型规模的n层应用程序，这里是我的中间层和EIS层的建议：
分隔各个子系统的实现和揭露它的功能通过一个服务接口并隐藏实现直接使用或引用。
为每个子系统创建一个JAR（或EAR）文件，并确定上述子系统/ JAR之间的运行时间和编译时间依赖性。
花费大量时间来确定服务接口方法和子系统依赖关系的正确粒度。
在此过程中，尝试为每个模块标识DAO层（假定涉及到数据库）并为每个子系统分隔数据库表。
对于网络层，请尝试按照以上方法通过由子系统对表示层进行分区来执行上述操作。为每个子系统创建一个WAR文件。如有必要，尝试将表示层WAR放入上面标识的相应EAR文件中。
上述体系结构的一个很好的验证就是在OSGi中使用每个服务作为OSGi服务（在创建适当的清单文件之后）部署它。
请记住，如果需要，也可以在任何这些子系统之间设置基于事件/异步通信。
这提供了一个拆分子系统的机会，并将它们部署到服务器的不同服务器场中，以获得更好的可扩展性机会。
祝你好运..！
我认为你可能会找到一本书（[在线查看]）（http://books.google.co.uk/books?id=9CL446IzhuAC&pg=PA38&lpg=PA38&dq=events+chapter+one+coupling&source=bl&ots= qmJTOuCz90与SIG = EZKvZBjF8QmGohatC97HsmAqG0c＆HL = EN＆EI = wj6tTqe5LcTX8gON_YyiCw＆SA = X＆OI = book_result和CT =结果＆resnum = 6＆VED = 0CEMQ6AEwBQ＃v = onepage＆q =事件％20chapter％20one％20coupling＆F = FALSE）） “基于事件的编程：服用事件到了极限 ” 别拿面值的题目 - 第一章给出了一个有洞察力的描述和方法，以减少/转移耦合到较少形式的耦合行为。 – 2011-10-30 12:23:08