目录
思考和整理自己日常工作中架构相关事项,以班为单位,提交信息汇总
1、自己工作中的哪些任务是跟架构相关的?
2、能否大概描述自己负责的/做过的业务系统的业务需求和大概流程?
3、能否讲清楚自己目前负责的系统使用的各类技术,框架,以及组件,模块等
思考和整理自己日常工作中架构相关事项,以班为单位,提交信息汇总
1、自己工作中的哪些任务是跟架构相关的?
- 近一年工作中,有涉及过一次dubbo项目重构为sofa框架的项目改造,在这个期间主要的内容分为几个部分:
- 另外还有一次是负责系统的ERP模块的设计实现工作,在这个任务期间,对输入输出的公共报文体的思考和定义;数据的解析校验,公共处理部分,业务处理模块的划分;与原系统的的对接整合与解耦合;ERP接口文档的编写和外部系统的对接,有了更进一步的思考和探索与学习
- 总体用一句话来描述我对我设计的erp系统的定位:类似于网关模块的一个概念,但也不完全相同:它既做与外部系统与主系统的桥接关系,也对主系统仅做服务接口引用达到数据获取的目的,此外所有复杂的数据处理逻辑均在erp系统中各自erp接口模块中自行实现;达到既连通,又相对独立的目的。
2、能否大概描述自己负责的/做过的业务系统的业务需求和大概流程?
- 我主要负责主系统中交易模块的需求开发与日常维护,今年开始基本以维护为主。需求大概就是实现企业创建付款单据然后提交审批复核,最终生成指令做实际交易,以及交易后期的相关业务;
- 流程相对复杂,总体来讲大部分逻辑体现在前端的付款制单的业务流程、校验流程、和整个流程面临的各类分流分支处理上,当然提交到后端后仍然会进行统一套但略微有区别(主要是顺序性和关联性和流程性没有前端那样强,但该有的校验均需要后端再控制一遍,不满足则报错,这是处于安全性与实时性的考虑)。期间涉及各大中台与关联系统的对接与维护工作,实现系统校验的正确性和时效性,这也简便了整个付款逻辑的复杂度,但同时也带来了维护成本的大幅增加(沟通成本、也带来了一定的强关联性,比如中台服务挂掉了,系统支付业务就无法继续进行,但这也是合理的,因为实际交易也是交易中心与核心及统一支付系统处理,中台宕机理应无法交易)
3、能否讲清楚自己目前负责的系统使用的各类技术,框架,以及组件,模块等
- 大概能理清楚主系统涉及和使用到的技术和组件有哪些、如何使用的,应用场景是哪些,划分模块的根据和理由是什么。自我评价,对系统的熟练和认知程度表面而言应该是在80%的样子,对具体组件的深刻理解上还远远不够,大概在40%的程度,后续应该考虑两个问题:
- 横向:如果我要用xxx替换当前使用的xxx,会有什么不同,两者优劣在哪?对系统带来的影响和改动有哪些?
- 纵向:当前使用的这个组件和技术还具备哪些能力,能否应用到系统中?当前系统面临的某些瓶颈是否可以通过部分组件的合力应用达到优化的目的?这个组件和技术的实现原理是什么,为什么会是这样?
本文作者:Golovin
本文链接:
版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA
许可协议。转载请注明出处!