轻量级架构设计工具
首先，我们再来总结下构件模型的抽象结构，结构如下图所示：
每个业务领域下都可能有一到多个装配模板用于设计产品；装配模板则由若干个构件组成，产品的组装式开发就表达为构件与模板间的对应关系，可以在构件中记录复用推荐度，以方便后续做设计时使用；构件中会对应多个参数，参数尽量使用数据模型中的数据项，但是实际操作中也可能需要列入一些与业务无关的技术字段，此外，应该给每个参数注明是否为可装配参数，不可装配的参数不提供面向业务人员的配置功能；一个构件对应一到多个实际的服务，构件此时代表的是一个服务集合，所谓复用不是任意去复用构件对应的服务，而是这些服务整体对外提供一个能力，这才是“零件”的含义，否则，构件就不是一个真实的存在，如果原有构件中的一部分服务又被集合成了新的能力，则应再增加一个构件进行对应；服务由于可以被调用，因此会对应报文，既包括请求报文也包括响应报文，报文中又会包含构件对应的参数，二者可以合二为一，也可以分开表达；装配模板在生产中，经过赋值产生可售产品；每个可售产品又会有描述性的属性信息，这些信息的集合就形成了产品目录。以上就是构件模型的逻辑关系，基于这个逻辑关系，结合系统设计原理，可以形成一个轻量级的架构设计和管控工具，其逻辑示意图如下：
从系统设计原理的角度来讲，系统的设计主要关注行为和数据两个方面，金融领域中，系统设计主要是为了实现产品，因此，系统是为了支持一到多个产品而存在的，系统及其支持的产品是用户视角的系统可见部分；过渡到设计部分，可售产品由装配模板配置而成，装配模板实际上是一种领域模型，不同领域的产品可能差异较大；装配模板之下是构件，构件代表了一个领域的具体组成部分，是“零件”，构件中包含数据，也就是参数；这些又进一步分解为服务，服务实际上既包含了行为，又包含了对应的数据，“微服务”在设计上尤其如此，服务作为设计上的底层核心元素，可以从统计角度包含归属组件、归属系统、归属用例、语言类型、代码行数、原初开发或累积的人月数、归属团队等等可用于项目管理的信息，其中有些信息可以通过工具和配置信息获得，有些需要人工维护，但是其所累积起的项目信息库对于大型企业的项目管理而言非常有价值。进一步将其工具化后，可以基于构件模型建立起一个从业务直通深层实现的轻量级架构工具。
该工具优势如下：
- 便于业务人员理解深层设计，从而加大业务人员参与度，提升业务与技术的融合；
- 能够有效表达系统的可组装程度和组装方式，加快需求分析、定位和设计的速度，提高沟通效率，尤其是对于跨组件、跨部门、跨团队的设计；
- 通过对底层服务的详细描述，可以累积项目自身的数据信息，便于进行快速的成本测算、可行性评估，项目预算其实一直是大企业的困扰，缺乏有效的估算方式，又难以结构化地利用历史数据，通过这种方式，将成本分摊到细节开发元素，能够提升评估的准确性，减少项目预估结果的波动性，再基于实际支出情况不断调整，可以逐渐提升其精确性。
不足之处，显然，需要投入一定精力去维护，不过这种精力上的支出应该是与项目同步付出的，不要搞成后补之类的处理方式。
应用场景设想
作为架构设计和管控工具，自然要通过它去分析和管理新需求，通过上节的介绍，构件模型可以形成新的流程表达方式，不同于业务模型是基于角色和职责，构件模型基于系统结构和关系，通过一条顺序流“串”起构件，形成完整的业务处理过程，因此，新需求可以快速定位到系统的修改位置，如果是需要新增构件，则很容易可以定位到需要增加构件的位置，分析新构件与原有构件的关系，最重要的是，这一切可以很方便地由产品经理、业务人员完成，并加快业务人员和技术人员的沟通速度。过程示意图如下：
模型最重要的是形成通用语言，而语言最重要的练习方式是经常使用，要想经常使用则必须与行为活动密切相关，所以，模型必须与设计有紧密联系，才能够被经常使用，使用越多则沟通越容易，也越被大家接受去用于沟通，沟通多了自然就通用了。
