平台整体结构

在产品开发过程中，为了达到业务级别的较大粒度重用，我们需要把纵向把业务进行拆分，以业务组件的形式进行开发，并最终把多个开发完成的业务组件进行组合，形成最终的软件产品。

按照组件化开发的产品，是基于一个公共的产品开发平台来建立的。由平台来提供所有的底层设施。平台包括技术平台和业务平台两个层面。在技术层面上，平台提供了一系列的类库、框架、组件、工具，以及为业务组件化提供相应的技术支撑。在业务层面上，业务平台中积累了大量的封装完善的业务组件，以及一些常用的业务控件，以供开发新产品时进行选配。同时，平台还为整个软件过程提供一系列的其它支持，例如工具、设计器、管理界面等。

下图，是平台的整体结构图：

图中罗列了大部分的关键组成部分，细节本篇不述。

组件集成平台

对于一个独立的业务，我们可以将其封装为一个独立的业务组件，并最终放到组件库中。业务组件之间，则以服务、事件两种形式进行交互。要支持这种模式的交互，技术平台还需要提供几个技术框架：插件平台、服务容器、事件总线。

下图是组件集成架构：

• 技术平台提供事件总线、轻量级服务总线。
• 组件内部以领域驱动的模式开发，以领域实体框架作为基础框架。组件内、组件间，也都是面向领域实体来进行交互。
• 组件向外部的其它组件提供组件事件、组件服务。外部组件也只能直接调用组件提供的服务，或者监听组件的事件。
• 组件还提供了一些可重用的 UI、一些可直接使用的分布式服务。
• 整个应用系统在组合多个业务组件后，再开发一些特定的功能、UI 就可以完成一个完整的系统了。

产品构成

下图是一个完整产品的组件构成图：

由于我们的产品开发平台必须要支持 721 客户化定制，所以同一个业务组件还对应不同的业务通用级别进行划分：Organization Common 表示组织架构组件最通用的部分，Org Part1 表示组织架构组件的可选包。而 Customiztion 则可以对引用的业务组件做深入的定制和扩展，而不需修改引用组件的代码。

可以看到，对于整个产品来说，在引用了业务组件库中的一些业务组件后，就可以组成了产品的基础功能。Customer App Component 中是应用系统在组件的功能基础上需要再做的工作：完成产品的额外功能，并通过平台接口为一些组件做相关定制。

组件内部架构

对于单个的业务组件，其内部的架构依然采用领域驱动的分层架构：

图虽大，但并不复杂，就是领域驱动的经典分层：Distribute（DTO 接口层）、Application（应用层/领域逻辑层）、Repository（仓库）、Domain（领域实体）。

重点在于 Domain 包，它不但包括领域实体，还包括了组件事件、组件服务接口，这些都是领域的核心。

位于底层的技术平台，提供一系列支持：IOC/AOP、属性扩展框架、领域实体框架、721定制化框架、数据库生成框架等……

结尾

其实，组件化架构设计中，最为复杂是分析出一个封装完好的组件，所要面向的使用者是哪些，这些使用者分别对组件有哪些需求，而这个架构如何满足这一系列需求。例如，我们在设计过程中，对这些方面进行了分析：组件自身的发展需求、组件中各组成部分的可扩展性、组件间的交互需求、系统集成需求、项目组定制化需求、系统外交互需求、易用性。

本文转自BloodyAngel博客园博客，原文链接：http://www.cnblogs.com/zgynhqf/p/3875912.html，如需转载请自行联系原作者