微内核架构（有时候即是指插件架构模式）天生适合实现基于产品的应用。基于产品的应用是一种按版本打包下载使用的应用，是典型第三方应用。
然而，许多公司也开发和发布像软件产品那样，开发和发布其内部的业务应用，带有版本号，发布说明和插拔特性（不太通顺）。这种情形也非常适合用这种模式。微内核架构可以让你以插件的形式添加额外的应用特性到核心应用，提供了扩展性而又保持特性的分离和相互独立。
模式描述
微内核架构模式包括两种不同的架构组件：核心系统和插件模块。应用逻辑被分解为相互独立的插件模块和基础核心系统，提供了扩展性，灵活性和系统特性和自定义处理逻辑的独立。图3-1示意基础微内核架构。
图3.1微内核架构模式
微内核模式的核心系统通常只包含能够使系统运行的必备的最小功能。好多操作系统实现了微内核架构模式，这正是这种模式名字的由来。 从业务应用的角度看，核心系统通常定义通用业务逻辑，而不包含特殊用例，规则或是复杂条件处理先关的自定义代码。 插件模块是独立存在的组件，其中包含特殊处理，额外的特性和用于加强或是扩展核心系统产生额外业务能力的自定义代码。通常插件模块之间应该相互独立，但是你也可以定义依赖于其他插件的插件。不管怎样对于避免依赖问题，保证插件模块之间的通信最小化是非常重要的。
核心系统需要知道哪些插件模块可用哪里加载它们。一个常用的实现方法是通过插件注册。注册表中包含每个插件模块的信息，其中包括名称，数据协议和远程访问细节（依赖于插件怎样连接到核心系统）。例如，税务软件中标记高风险税务项的插件，有一个注册入口包含服务名称（AuditChecker），数据协议（输入和输出数据）和协议格式（XML）。如果插件是通过SOAP访问，有可能包含WSDL(Web Service DfinitionLanguage).
插件模块能通过各种方法连接到核心系统，包括OSGi(opern service gateway initiative )，消息，web service，或是直接点对点绑定（如对象实例）。你所使用连接的类型依赖于你要创建应用的类型（小型产品或是大型业务需求）和你的特定的需求（单点应用或是分布式应用）。这种模式本身不指定这些实现细节，除了必须要插件之间保持相互独立性。
插件模块和核心系统之间的协议既可以是标准协议也可以是自定义协议。自定义协议常见于第三方开发的插件，而你并不能控制插件使用的协议。这种情况下,通常会为插件协议和你的标准协议之间创建一个适配器，一般核心系统不必为每一个插件都编写特例代码。当创建标准协议（通常通过xml或是java Map实现）时，一开始就创建一个版本策略是非常重要的。
模式举例
微内核架构最好的例子有可能是eclipse Ide。刚下载的eclipse基础产品不过是一个稍好一点的编辑器。不过，一旦你开始添加插件，它就会变成一个高度定制的有用的产品。互联网浏览器是另一个使用微内核架构的例子：不同视图和其他插件和其他额外的特性是基础浏览器所不具备的。 (i.e.,core system).?
基于产品有数不完的例子，那么大型业务应用呢？微内核架构也适用于这种情形。为了说明这点，让我们再举一个保险公司的例子，但这次我们引入保险索赔的处理。索赔处理是一个非常复杂的过程。针对在保险索赔中什么允许什么不允许，每个州都有不同的规则和惯例。例如有的州规定如果你的挡风玻璃被岩石砸坏的话可以免费更换，而有的州却不会。这会为标准索赔流程创建一个无穷的条件集合。
毫不奇怪，绝大部分保险理赔系统维护一个庞大且复杂的规则引擎来应付复杂性。然而规则引擎会会成长为一个大泥团，一旦你修改其中一条规则就会影响其他规则，或是做一个简单的规则编程需要一支大军包括分析师，开发人员和测试人员。使用微内核架构可以解决其中的许多问题。
在图3-2看到的一堆文件展现了索赔流程的核心系统。其中包括保险公司处理索赔所需要的基本业务逻辑，不包括特例。每个插件模块包含那个州的特有规则。在这个例子里，插件模块的实现可能是用户源代码也可能是其他的规则引擎实例。不考虑实现，关键点在于特定状态规则和处理一定要和核心系统区别开来，而且可以添加，删除，修改并且对其他插件模块和核心系统没有或是只有很小的影响。
[图片]
图3-2 微内核架构举例
思考
微内核架构比较牛逼的一点是他可以和别的架构模式嵌套使用，或是作为其他架构模型的一部分。例如，如果这种模式解决了一个特殊问题，例如你应用中经常改变的部分,你会发现你可以用这种模式实现整个架构。这种情况下，你可以把微内核架构嵌入到你正在使用的另一个模式中（例如分层架构）。于此相似，上一部分 事件驱动模式中描述的事件处理器（event-processor）组件可以用微内核架构实现。
微内核架构模式为进化设计和增量开发提供了强大的支持。首先你可以先打造一个坚固的核心系统，随着应用的增长你可以添加特性和功能而不必对核心系统做重大改变。
对基于产品的应用，微内核架构模式永远是初始架构的第一选择，特别对于一些产品你会随着时间发布一些特性，并想要控制那些用户能够获取相应特性。如果随着时间你发现这种模式不能完全满足你的需求，你完全可以把你的应用重构成更适合你特殊需求的架构模式。
模式分析
下表是针对微内核架构的通用架构特征的比率和分析展示。每个特征的比值是基于这中模式典型实现估计的，这些比值也广为人知。为了清晰的对比这种模式和这篇报告中其他模式的相关性，请参照报告结尾的附录A。
整体灵活性
比值：高
分析：整体灵活性是应对不断变化环境的一种能力。改变能够被极大的隔离和快速的实现通过松散耦合的插件模块。总的来说，大多数微内核架构模式的核心系统趋向于快速稳定，本身健壮性强，随时间变化较少。
易发布性
比值：高
分析：依赖于模式的实现，插件模块可以在运行时动态的添加到核心系统（热发布），发布期间最小化停工期。
可测试性
比值：高
分析：插件模块可以被分开测试
