完美和拖延程序员中的很多人都是完美主义者在工作对自己的要求是一丝不苟不能出一丝一毫的错误交付给领导的技术方案连个错别字都不能有线上也不能有bug无论是主动或被动很多人都有在追求完美主义。这里面也包括我~大概一年前我就有一个想法做一个开源项目————订单中台系统但是一直没有付诸行动我给自己的解释是我还没有想好如何设计很多决策点困惑着我一来二去拖了非常久的时间。直到去年过年我有大把的时间闲得无聊我不想再等了想不明白也要开搞我决定先搭建一套 SpringBoot应用把常见的框架中间件先引入进来。先做一个垃圾出来我发现当我抱着做完这件事而不是把这件事做完美的想法去做事以后事情有了很大的进展引入MQ/DB/Redis/Mybatis/SpringCloud等等框架和中间件把项目搭建好仅用了一天半不到剩下的半天我把项目里的工具类、基础组件写好包括扩展点引擎和流程引擎。万事开头难可以先从自己最熟悉最擅长的部分开始入手~扩展点引擎扩展点引擎是我很早之前就想明白同时在业界也是广泛采用的办法它解决的痛点是交易系统中台要接入很多的业务方每个业务方并不是完全相同。很多时候无法完全复用需要改造系统适应新的业务。对于一个复杂的多业务并存的交易系统新增业务代码时务必要保证原有业务不受影响如果没有插件扩展能力就会充斥大量的 if else 。因此项目开发初期我完成了插件扩展点引擎的开发用了不到半天一两百行代码但是很关键可以很好解决业务隔离性差和扩展难 的问题。调研流程引擎我还花了一天的时间调研了流程引擎框架LiteFlow但是调研以后发现它的流程设计和我预想中不太一样我期望的流程引擎执行时每个节点类似于过滤器链条中的1个节点当流程失败以后执行各个节点的回滚方法但是LiteFlow只能顺序的执行每个节点不能回滚。因此我决定自己写一个流程引擎很简单的那种花了大概不到半天实际用起来发现很好用~不要等到百分百想明白再干而是在干中想干中学慢慢就全明白了~机-会技术大厂前端-后端-测试全国均有机-会感兴趣可以试试。待遇和稳定性都还不错~不断推翻重来开工以后项目经历了三次大的修改其中最大的1次我将设计好的数据库模型全部推翻把之前写的代码全部删除重写一遍重新梳理思路重新设计。之前在设计订单系统时我把交易下单部分和履约部分分拆成两个独立的模型后来发现完全没有必要履约只是订单交易系统的一个模块。下单、消单、履约、退款是在订单模型上驱动订单状态改变并执行其他业务动作。订单履约没有必要抽出和订单模型一对一的模型。当然这是有前提条件的MemberClub目前的定位是虚拟订单系统它的履约模块的业务复杂度相比实物订单配送履约系统是简单不少的所以没有必要单独抽离出履约单模型反而抽出履约单模型会增加系统的复杂度和理解难度。如无必要勿增实体。我不认为被删除的代码是做了无用功恰恰相反我认为如果没有这次试错我就算干想一万年也可能想不明白这件事。经过这次修改以后我脑海里不成熟的想法逐渐成熟。最后如果欢迎掘友们加入我的开源项目 MemberClub欢迎关注。它可实现一天时间内搭建一套订单交易系统。 轻量级完全开源的交易引擎以SDK方式对外提供通用的交易能力能让开发者像搭积木方式从0到1快速构建一个新的电商交易系统github: github.com/juejin-wuya…gitee: gitee.com/juejinwuyan…——转载自五阳