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