Question

我目前正在从头开始设计一个系统，我们遇到了一个建筑设计场景，我不确定最好的解决方法 - 但我确信其他人都有解决了，甚至可能是它的模式。

到目前为止的故事：

我们有一个多功能的网站，我们在其中实现插件的各种功能，我们的客户将选择他们希望在他们的应用程序中使用哪些插件。每个插件都可以有各种各样的小部件＆＃34;用户可以添加到页面。（例如，类似于Android应用程序通常带有可添加到主屏幕的小部件的想法）。

插件可以依赖于其他插件来启用（例如，电子商务插件需要Payments插件）。插件也可以使用其他插件来增强其功能（例如，Blogs插件可以选择使用评论插件，也可以使用评论与电子商务产品）。

尽可能地，我们希望每个插件都是自包含的，具有非常瘦的plublic接口。我们相信这种关注点的分离将为我们提供最佳的长期灵活性和整体系统的可维护性。

问题：

当我们开始布局我们目前所知的所有插件（更不用说未来的需求），以及它们的依赖性和与其他插件的可能关系时 - 它开始与疯狂的蜘蛛网非常相似。我们也开始看到一些循环参考发生。

例如，导航插件需要知道网站上的页面。但您也可以向页面添加导航窗口小部件。

部分/潜在解决方案：

我们认为每个插件应该与其他插件完全分开，但是会从消息中获取信息并与其他插件通信。这些消息可以分为两种基本类型

这两种消息类型都是非常简单的DTO类型 - 它们不应包含任何业务逻辑 - 只是处理请求的其他服务所需的信息，并提供响应。

我已经嘲笑了几个插件的非常简化的版本，我们看到他们与其他插件的交互解决方案是：http://screencast.com/t/Mdb9wUmMF

在此图表中，导航，页面，搜索和其他插件对彼此不了解。但是他们会了解可用的消息和ProcessMessages接口。

例如请求/响应消息

导航和其他插件会知道，如果它向ProcessMessages发送GetPagesRequest，它将返回一个包含所需信息的PagesResponse。（Nav / Other插件需要立即响应GetPagesRequest。）

导航和其他插件对页面插件一无所知。

请求/响应消息要求

引发请求消息的插件总是（通常是？）会立即发出响应消息。

只有1个服务知道如何处理请求消息，并提供将被传递回调用插件的响应消息。

例如事件消息

当用户更新页面插件中页面的URL时，插件会向ProcessMessages发送PageUrlUpdated消息。然后，导航和其他插件将使用PageUrlUpdated消息并执行所需的任何操作。

活动讯息要求

引发事件的插件永远不会期待响应。 0-许多插件可能会消耗给定的消息。

（技术说明：对于事件消息，我们将把它们发送到MassTransit和RabbitMQ - 然后每个消息都有1-n个消费者）

问题

从我们制作的几个草图中，上述想法似乎有效，并且系统的不同元素之间的相互依赖性要小得多。但我不知道设计模式或建筑结构的名称 - 或者我是否完成了错误的轨道。我希望有人能指出我正确的解决方案 - 一些好的文档和例子会非常好。（试图避免重新发明轮子 - 现有模式可能会更加强大和成功）
对于Request Messages，我们设想了一种从请求消息到处理消息的具体插件/服务的某种StructureMap-ish映射。再一次 - 我确信之前已经解决了这个问题，并且已经解决了这个模式，或者我们完全走错了轨道并且有更好的解决方案。

非常感谢任何帮助和想法 Saan

PS - 我在一个具有一些基本属性的公共项目中也有一个IWidget - 所以Pages插件可以只请求实现IWidget的所有类添加到页面

Answer 1

你的问题有很多不同的方法;但我可能会建议面向服务的架构。主要是因为它可以以非常快速和敏捷的方式适应业务。这种架构提供了许多奖励：

然而，它确实带来了一系列可能需要克服的障碍，例如：

因此，实施其中一些决议可能会缓解这一问题。但是，这需要您自己掌握一些相关知识。由于这种架构很灵活，但一切都暴露在一定程度上。另外，实例化多个实例呢？

这些都是您必须识别的潜在项目。

我个人会做的是找到业务的真正核心 - 而不是项目;但是生意。然后确定哪种方法最能完成该任务。这将是一个持久的模式，因为业务核心是它的核心。

我在这件事上强烈推荐的一些事情是：

还有很多其他可行的书籍，但我发现这些书籍非常有帮助。因为他们最终涉及大量的设计讨论：

这将填补几个空白;但我不能强调。 没有技术比彼此更好，它们都有利有弊。但是，最能实现业务目标的技术是理想的选择。

我理解您需要回复来帮助您，但请记住：

         Ask not the Elves for counsel, as they both say yes and no.

仅仅因为我们不了解您的项目或您的业务，这些目标将严重影响您的决策。那些只有你才会知道的东西。正如我所陈述的那样，我们不知道您会想要解释：

还有更多，但你必须考虑一些变量，因为腐烂的应用率会停滞一段时间。因此，应用程序的生命将持续相当长的一段时间。

希望这有帮助，但那是我的两分钱。