微内核体系结构模式及其在业务应用中的适用性

Question

我们的业务是建立可定制的网络应用。我们有一个核心团队，提供我们所谓的核心平台(提供安全、计费等服务)。核心产品都是建在上面的。这些核心产品是特定于行业的解决方案，如电信、公用事业等。这些核心产品后来被其他团队用于在特定行业构建特定客户的解决方案。

到目前为止，我们有一个松散的分离平台和核心产品。客户特定的解决方案是通过定制20-40%的核心产品和重新包装.核心平台和核心产品作为单一应用(ear)一起发布。

我希望改善目前的情况，以便在这3上有一个更干净的分离，这使我们可以分别进化这3种，等等。

我已经阅读了微内核的体系结构和感觉，我可以在我的上下文中采纳和应用这些原则。但是我所读到的大多数关于这种模式的文章都是在操作系统或应用服务器等环境中进行的。我想知道是否有任何关于如何使用该模式来架构业务应用程序的例子。或者，您可以提供一些关于如何将该模式应用于我的问题的一些见解。

Answer 1

这是一个“模块”模式，也是一个“人”模式--您的代码看起来也可能不一样，但这并不是区别之处所在。我认为你理解你想要应用它的情况下的模式是什么。

实际应用它看起来如下所示：

假设核心平台是“堆栈”中的最低层。

在代码中，这三个层将位于不同的包中--您可能已经有了这些包。确保下面的层没有对上面层中的某些内容进行任何特定的引用或依赖。这将保护您的平台不受复杂的产品和特定于客户的东西。在任何层和它下面的层之间创建一些外观和其他简单的抽象。例如，我对核心平台中的数据库模块的外观可能由一个工厂组成，该工厂将生成一个遵循"DataSource“接口的实例，而不是您的核心产品团队中的某个人直接进入核心平台(而不是通过Facade)并具体实例化一个SQLDatabaseSource。这将保护您的产品和客户层不受平台实现中的更改。

其次，团队的结构必须以一种概念上与“下游”方法相匹配的方式进行有效的沟通。平台团队必须对Product最需要的特性表现出兴趣，清晰地记录如何使用它们，并且干净地设计它们，这样客户团队就不必将它们的实现紧密地耦合到它。他们还必须明确他们不愿意或不能容纳下游团队的方式。也许他们会有最慢的周期，而不是您的客户团队，他们的涉众较少(1家客户公司，而不是您的平台团队最终可能提供的100家)允许更快的迭代。

有鉴于此，我认为您可能需要重新考虑“核心产品”这个名称，因为在“核心”平台之上构建“核心”产品只是让人困惑。核心意味着内部，所以只有一个可以是。

真不敢相信他们把这个从堆叠溢出中取下来了