分享：尝试构建轻量级架构设计工具

轻量级架构设计工具

首先，咱们再来总结下构件模型的抽象结构，结构以下图所示：

​

每一个业务领域下均可能有一到多个装配模板用于设计产品；装配模板则由若干个构件组成，产品的组装式开发就表达为构件与模板间的对应关系，能够在构件中记录复用推荐度，以方便后续作设计时使用；构件中会对应多个参数，参数尽可能使用数据模型中的数据项，可是实际操做中也可能须要列入一些与业务无关的技术字段，此外，应该给每一个参数注明是否为可装配参数，不可装配的参数不提供面向业务人员的配置功能；一个构件对应一到多个实际的服务，构件此时表明的是一个服务集合，所谓复用不是任意去复用构件对应的服务，而是这些服务总体对外提供一个能力，这才是“零件”的含义，不然，构件就不是一个真实的存在，若是原有构件中的一部分服务又被集合成了新的能力，则应再增长一个构件进行对应；服务因为能够被调用，所以会对应报文，既包括请求报文也包括响应报文，报文中又会包含构件对应的参数，两者能够合二为一，也能够分开表达；装配模板在生产中，通过赋值产生可售产品；每一个可售产品又会有描述性的属性信息，这些信息的集合就造成了产品目录。以上就是构件模型的逻辑关系，基于这个逻辑关系，结合系统设计原理，能够造成一个轻量级的架构设计和管控工具，其逻辑示意图以下：

从系统设计原理的角度来说，系统的设计主要关注行为和数据两个方面，金融领域中，系统设计主要是为了实现产品，所以，系统是为了支持一到多个产品而存在的，系统及其支持的产品是用户视角的系统可见部分；过渡到设计部分，可售产品由装配模板配置而成，装配模板其实是一种领域模型，不一样领域的产品可能差别较大；装配模板之下是构件，构件表明了一个领域的具体组成部分，是“零件”，构件中包含数据，也就是参数；这些又进一步分解为服务，服务实际上既包含了行为，又包含了对应的数据，“微服务”在设计上尤为如此，服务做为设计上的底层核心元素，能够从统计角度包含归属组件、归属系统、归属用例、语言类型、代码行数、原初开发或累积的人月数、归属团队等等可用于项目管理的信息，其中有些信息能够经过工具和配置信息得到，有些须要人工维护，可是其所累积起的项目信息库对于大型企业的项目管理而言很是有价值。进一步将其工具化后，能够基于构件模型创建起一个从业务直通深层实现的轻量级架构工具。

该工具优点以下：

1. 便于业务人员理解深层设计，从而加大业务人员参与度，提高业务与技术的融合；
2. 可以有效表达系统的可组装程度和组装方式，加快需求分析、定位和设计的速度，提升沟通效率，尤为是对于跨组件、跨部门、跨团队的设计；
3. 经过对底层服务的详细描述，能够累积项目自身的数据信息，便于进行快速的成本测算、可行性评估，项目预算其实一直是大企业的困扰，缺少有效的估算方式，又难以结构化地利用历史数据，经过这种方式，将成本分摊到细节开发元素，可以提高评估的准确性，减小项目预估结果的波动性，再基于实际支出状况不断调整，能够逐渐提高其精确性。

不足之处，显然，须要投入必定精力去维护，不过这种精力上的支出应该是与项目同步付出的，不要搞成后补之类的处理方式。

应用场景设想

做为架构设计和管控工具，天然要经过它去分析和管理新需求，经过上节的介绍，构件模型能够造成新的流程表达方式，不一样于业务模型是基于角色和职责，构件模型基于系统结构和关系，经过一条顺序流“串”起构件，造成完整的业务处理过程，所以，新需求能够快速定位到系统的修改位置，若是是须要新增构件，则很容易能够定位到须要增长构件的位置，分析新构件与原有构件的关系，最重要的是，这一切能够很方便地由产品经理、业务人员完成，并加快业务人员和技术人员的沟通速度。过程示意图以下：

模型最重要的是造成通用语言，而语言最重要的练习方式是常用，要想常用则必须与行为活动密切相关，因此，模型必须与设计有紧密联系，才可以被常用，使用越多则沟通越容易，也越被你们接受去用于沟通，沟通多了天然就通用了。

 获取更多Java高级架构最新视频， 加入Java进阶架构交流群：142019080。直接点击连接加群。https://jq.qq.com/?_wv=1027&k=5lXBNZ7