软件企业为了提高开发效率，越来越注重软件元素的复用（也称重用），因此，架构设计师在进行架构设计时，必须关注复用，例如，考虑丰富企业构件和充分使用已有的构件。
与复用技术密切相关的概念是构件（ component ，组件），业界对构件还没有公认的定义，如下为几种常见的定义。
定义1：构件是指软件系统中可以明确辨识的构成成分。而可复用构件（reusable component ）是指具有相对独立的功能和可复用价值的构件。 定义2：构件是一个组装单元，它具有约定式规范的接口及明确的依赖环境。 定义3：构件是软件系统中具有相对独立功能 、 可以明确辨识 、 接口由契约指定 、 和语境有明显依赖关系 、 可独立部署的可组装软件实体。
对构件更广义的理解是把所有种类的工作成品（例如，各类文档 、 方案 、 计划 、 测试案例 、 代码）都看成是可复用的构件。
1 商用构件标准规范
当前，主流的商用构件标准规范包括 OMG （ Object Management Group ，对象管理组织）的 CORBA、SUN 的 J2EE 和 Microsoft 的 DNA。
1.1 CORBA
CORBA （ Common Object Request Broker Architecture ，公共对象请求代理架构）主要分为3个层次：对象请求代理 、 公共对象服务和公共设施。
最底层的对象请求代理（ Object Request Broker ， ORB ），规定了分布对象的定义（接口）和语言映射，实现对象间的通信和互操作，是分布对象系统中的 “ 软总线 ” ；在 ORB 之上定义了很多公共服务，可以提供诸如并发服务 、 名字服务 、 事务（交易）服务 、 安全服务等各种各样的服务；最上层的公共设施则定义了构件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。
CORBA CCM （ CORBA Component Model，CORBA 构件模型）是 OMG 组织制定的一个用于开发和配置分布式应用的服务器端构件模型规范，它主要包括如下3项内容。 （1）抽象构件模型：用以描述服务器端构件结构及构件间互操作的结构。 （2）构件容器结构：用以提供通用的构件运行和管理环境，并支持对安全 、 事务 、 持久状态等系统服务的集成。 （3）构件的配置和打包规范： CCM 使用打包技术来管理构件的二进制 、 多语言版本的可执行代码和配置信息，并制定了构件包的具体内容和文档内容标准。
1.2 J2EE
在 J2EE 中， SUN 给出了完整的基于 Java 语言开发面向企业分布的应用规范，其中，在分布式互操作协议上， J2EE 同时支持 RMI （ Remote Method Invocation ，远程方法调用）和 IIOP （ Internet Inter-ORB Protocol ，互联网内部对象请求代理协议），而在服务器端分布式应用的构造形式，则包括了 Java Servlet、JSP、EJB等多种形式，以支持不同的业务需求，而且 Java 应用程序具有跨平台的特性，使得 J2EE 技术在发布计算领域得到了快速发展。
1.3 DNA 2000
Microsoft DNA2000 是 Microsoft 在推出 Windows2000 系列操作系统平台的基础上，在扩展了分布计算模型，以及改造 Back Office 系列服务器端分布计算产品后发布的新的分布计算架构和规范。在服务器端， DNA2000 提供了 ASP 、 COM 、 Cluster 等的应用支持。 DNA2000 融合了当今最先进的分布计算理论和思想，例如，事务处理 、 可伸缩性 、 异步消息队列 、 集群等内容 。DNA 可以开发基于 Microsoft 平台的服务器构件应用，其中，如数据库事务服务 、 异步通信服务和安全服务等，都由底层的分布对象系统提供。 Microsoft 的 DCOM / COM / COM + 技术，在 DNA2000 分布计算结构基础上，展现了一个全新的分布构件应用模型。首先， DCOM / COM / COM + 的构件仍然采用普通的 COM （ Component Object Model ，构件对象模型）模型。 COM 最初作为 Microsoft 桌面系统的构件技术，主要为本地的 OLE （ Object Linking and Embedding ，对象连接与嵌入）应用服务，但是随着 Microsoft 服务器操作系统 WindowsNT 和DCOM （Distributed Component Object Model ，分布式构件对象模型）的发布， COM 通过底层的远程支持使得构件技术延伸到了分布应用领域。 DCOM / COM / COM + 更将其扩充为面向服务器端分布应用的业务逻辑中间件。通过 COM +的相关服务设施，如负载均衡 、 内存数据库 、 对象池 、 构件管理与配置等， DCOM / COM / COM + 将 COM 、 DCOM 、 MTS（ Microsoft Transaction Server，微软事物处理服务器）的功能有机地统一在一起，形成了一个概念 、 功能强的构件应用架构。
通过购买商用构件（平台）并遵循其开发标准来进行应用开发，是提高应用软件开发效率的常见选择。
2 应用系统簇与构件系统
除专门开发构件的企业外，开发应用系统的企业也会发展自己的构件应用体系：通常是随着企业的不断成熟，逐步从已开发的应用系统中整理出来一些构件，反过来，将这些构件复用到优化与整合已有应用系统中或复用于开发新的应用系统。
一个应用系统中的复用率毕竟有限，通常在应用系统簇中进行软件构件复用。当要开发若干相关的应用系统时，可以先按复用的要求，界定这一组应用系统的共同 “ 特性 ” ，根据这些共同特性，建立模型，并按照复用的要求，将模型分解成恰当规模和结构的构件，对这些构件进行设计 、 实现 、 打包 、 编写文档，形成方便使用的可复用构件。
这批可复用构件将用于支持该应用簇的各个应用系统的开发工作。这里的构件特指一个封装的代码模块或大粒度的运行模块。软件企业将相关的构件有机地组织在一起，形成构件系统（较构件库层次更高），实施复用的软件企业通常拥有多个构件系统，有的是购置的，有的是自己开发的。应用系统和构件系统都是系统产品（而不是工作产品）。它们都可以采用模型和结构的类型定义出来。
一般情况下，构件系统只在开发单位内部使用，而应用系统提供给外部客户，与应用系统相比，构件系统具有通用性，可复用性，这就要求构件系统的开发过程应当实施更为严格的工程规范。
一个构件系统是能提供一系列可复用特性的系统产品。构件系统中的构件应当是高内聚 、 低耦合的，但构件之间应有若干种关系；可以发送消息给其他构件；可以与其他构件联合，支持协同工作。构件系统应当是易于理解和易于使用的，对构件应当是仔细地进行建模 、 实现 、 制作文档 、 测试等，便于以后的有效维护和改进。通常为支持构件的复用，应开发与构件系统相配的工具箱。
应用系统可以向构件系统输入构件（构件的需求源于应用系统或应用系统中的模块），反过来，构件系统向应用系统输出构件。这就是构件系统如何获得构件和如何提供构件的方式。
3 基于复用开发的组织结构
基于复用的开发组织与传统的开发组织结构不同，它需要有一部分用于开发可复用资产的资源，这部分资源应同具体应用系统的开发资源分开，以确保不被占用。
一种较平衡的组织结构如图 1 所示，它有三类职能部门： 一是构件系统开发部门，它开发可复用资产； 二是应用系统项目开发部（多个），它复用资产； 三是支持部门，这个部门是可选的，它进一步隔离上述两主体部门，虽然牺牲了一些效率，但保证了构件的规范性。它的主要职责是对构件开发部门所提供的可复用资产进行确认 、 对构件库进行分类编目 、 向开发应用系统的工程师们发通告和分发可复用资产 、 提供必要的文档 、 从复用者处收集反馈信息和缺陷报告。可以这样理解：构件系统开发部门开发的构件系统由支持部门向应用开发部门推广，即支持部门是企业内的推广部。外部购买的商用构件也由支持部门维护与管理。
这三个平行部门之上有一个高层经理（复用经理），他关注总目标，协调相互关系。一方面，构件开发者应当尽量接近应用开发者，以使其开发出的构件能尽量符合实际需要；另一方面，构件开发者与应用开发者分属两个并列的部门，使构件开发者能摆脱应用项目的日常压力，保证可复用资产的开发和持续改进。
复用经理应当在构件开发和应用项目开发利益之间进行权衡，保证长期目标不受近期项目压力的影响。
