本架构主要目的是改进软件开发中松耦合、增加模块的重用性、提高开发效率。
在常规的模块间方法直接调用式开发中，新增的功能对原有模块代码的稳定性、重用性破坏大,不利于软件的后期维护，且开发效率低。
另外，在传统的软件开发方法中，如果新增的功能的逻辑在其它模块需要重复使用，则只能通过copy代码或方法调用的方式来重用，还是需要改动原代码。
通过本技术方案，可以将一些功能抽像为组件，这些组件可以被动态的插入的现有模块中，不需要改动原有模块代码，从而增加了重用性，提高了开发效率。
技术解决方案
A. 相关概念抽像及定义
首先在软件的业务模块中抽像出核心业务逻辑(Core Service)及核心业务数据(Core Data Model)，同时抽像出核心业务逻辑相对应的事件接口(Event Interface)。
在核心业务之外的业务被称之为组件(Component)，组件是由一组业务插件（Plugin）组成的，这些插件是一个或多个核心业务的事件的实现体，核心业务和事件的关联，
是通过插件桩（Plugin Bundle）收集起来的，具体的关联关系是在一个名为Component.xml(组件描述文件)中定义的。
B. 组件的开发
当需要在核心业务逻辑中插入新的逻辑时，需要定义出相应的插件，使插件实现相应的业务事件接口，在插件中实现具体业务逻辑代码，其需要的核心业务数据会通过事件接口做为参数传递过来，这样插件就可以无入侵式的操作核心业务数据了。
C. 组件的加载和启动
首先组件有以下状态：安装状态和启动状态，分别为已安装和未安装，已启动和未启动。
当系统启动时，组件加载模块查找所有的Component.xml，并解析出插件和核心业务的关联关系，并将这种关系通过组件视图（Component View）记录在内存中。
在加载过程中，检测数据中是否有此组件的记录，如果没有则在数据中记录，此时组件的状态被标记为未安装、未启动。如果数据库中已经存在则检测其状态，如果是已启动状态，则将此组件启动，并标记为已启动状态。
在系统的控制台中展示组件的列表，并提供操作按钮，可以执行以下操作：安装/卸载、启动/停用。
综上所述，组件被启动可能通过两种途径：系统加载时或在控制台中手动启动。组件被启动后，根据组件视图中记录的关系将插件和插件桩进行关系绑定，即将插件动态插入到插件桩中，即完成业务逻辑动态地、无侵入式地插入到核心业务逻辑中。
D. 插件调用逻辑说明
在软件运行中，当核心业务逻辑被调用的同时调用事件接口，同时向接口传递核心业务数据，这个过程被称为事件激发。
当事件激时，插件桩里已经收集了相应的插件集合（事件的实现体），进而在插件桩中一个个的调用插件，传递核心数据，这样插件被执行。
方案的效果
通过上述组件的技术方案，可以实现对原系统无侵入式的、松耦合式的开发，开发人员无需关系核心代码细节，只要了解事件接口就可以完成对核心业务的扩展，开发效率高、重用性高。
效果举例：以电子商务系统为例，在一个电商业务中创建订单是核心的业务逻辑，在订单创建成功后，可能需要发送一条手机短信给顾客， 基于此种组件方案，开发人员需要开发一款基于某个电信网关的短信发送组件。开发人员不必了解订单创建的具体代码，只需关心如何跟电信网关对接即可，组件机制会将订单信息、顾客手机号等核心数据通过订单的创建事件传递给插件，插件拿到上述数据， 根据具体接入的电信网关参数，将核心数据（订单信息、顾客手机号）组织好文字，传递给电信网关就完成了通过此短信网关发送订单短信的功能。
一旦业务发生变更，比如要更换其它短信网关发送短信，此时再根据具体的网关参数开发另一款短信组件，然后停用之前的短信组件，安装上新的组件即可。
可以看出，从功能开发，到后期的变更维护，订单创建的核心业务代码从未暴露给组件开发人员，他们也不需要去改动核心代码，保持了原有系统的稳定性，降低了新功能开发的难度，而且基于同样规则的系统都可以安装此短信组件，直接使用，极大的降低了开发成本。
实际应用
我们以本架构在javashop电商系统中的应用案例说明：
一、订单的创建和短信发送
A. 订单核心业务
1.订单核心业务（OrderService）
负责订单的创建，这属于电商业务的核心，通过createOrder()方法创建订单。
2.订单插件桩(OrderPluginBundle)
在其pluginList属性中存储了所有响应订单业务事件的插件。
3.订单创建接口
订在订单创建成功后，会激发此事件，而实际调用的是上述pluginList中的插件。
B. 组件的组成
如上图所示，订单短信组件由以下内容：
1. 订单短信组件（OrderSmsComponent）
订单组件类，在组件被安装时会调用其install方法，完成一些安装必要的操作。
2. 订单短信插件
此类实现了订单创建事件，响应了订单完成事件（onOrderCreate）方法，当订单创建完成时，会调用此方法。
3. 组件的描述文件Component.xml
此描述文件定义了订单插件（OrderSmsPlugin）要注入到订单插件桩中，即定义了插件要对应的核心业务
C. 组件加载、启动过程
组件的加载、启动过程细节如下：
当系统启动时，组件加载模块查找所有的，并解析出插件和核心业务的关联关系，并将这种关系通过组件视图记录在内存中。
在加载过程中，检测数据中是否有此组件的记录，如果没有则在数据中记录，此时组件的状态被标记为未安装、未启动。如果数据库中已经存在则检测其状态，如果是已启动状态，则将此组件启动。
组件启动首先将插件注入到相应的插件桩中，此时当事件被激发时，通过插件桩就可以调用到实现了此事件的所有插件了。组织好插件的关系后，将此组件在数据库中标记为已启动。
D. 事件激发及插件调用
如上图所示，描述了事件激发和插件调用的过程，具体技术实施细节如下：
在这里循环所有的订单创建事件调用之（激发事件接口），这些事件实际是被注入进来的、具体的插件实现体，比如订单短信插件，此时订单短信插件被动态调用，在此插件中完成发送短信的逻辑。
通过上述架构的实施，可以达到如下效果：
现在短信的厂商众多，我们分别为其实现“短信发送插件”，这对于“订单核心逻辑”代码是不需要改动的，
一方面提升了核心代码的稳定，一方面增加可对“新短信厂商”的扩展性。
后记
通过这种组件架构，其实在电商架构领域中还有很多模块可以采用组件式的架构，以javashop电商系统中的应用为例：
支付组件
订单的支付为核心逻辑，他来处理状态改变，记录日志等。
通过调用支付插件来完成具体的支付操作，传递的是支付金额，订单号核心标准数据。
而支付插件可以多种实现：支付宝、微信、银联等等。
这样增强了订单核心的稳定，提高了支付方式的扩展性
物流查询
查询动作和展示是核心，传递给插件“物流公司”，“物流单号”核心标准数据
物流查询有多种插件实现：kuaidi100，showapi，菜鸟等等。
同样增强了订单核心的稳定，提高了物流查询厂商的扩展性
图片存储
图片都上传和显示是核心，传递给插件图片流是核心标准数据
图片的存储有多种插件实现：如阿里oss,七牛、又拍等等。
同样增强了系统核心的稳定，提高了图片存储厂商的扩展性
其实还有很多逻辑可以采用这种思路，提高稳定性，提高扩展性，在这里就不一一列举
这需要对自己的系统功能进行分析抽象，抽象出核心逻辑、插件接口标准、标准数据。