电票的腐化过程

电票是17年上线的一个项目，主要功能比较简单，由两个主要部分组成，一个是电票的支付单，一个是电票，功能列表如下。

开发过程

数据表

项目按照以往的经验，先设计需要的表结构，其中包括支付单关联以及电票、电票请求三张表（参考了之前类似项目的经验），并在线下库新建了表以及表的DO模型、DAO操作等，并根据分工每人负责一个模块的开发（一共有三人小团队），直到将近两两联调时突然发现少了部分数据，由于关联表的操作，模型等都已经实现了，如果在这个表中修改，项目的时间肯定来不及，这个时候只好新增了一张表，然后再跟关联表通过数据关联起来，将本来只需要一张表完成的功能拆成了两张，大大的增加了系统的复杂度。

业务逻辑

业务逻辑采用的是事务脚本的方式，一个电票的管理类将近1600行，所有的逻辑都是按照业务规则平铺，例如当处理来票时，会先生成一个票据DO，然后尝试插入数据库，插入成功之后会发送消息；关联票据也类似，校验一系列业务规则之后更新数据库并发消息。

在第一期项目中这些逻辑也还好，并不算特别复杂，但是随着需求的不断新增，例如加入商票的逻辑，加入了系统自动核销的逻辑，加入部门隔离的逻辑；电票管理类的职责也越来越多，需求的响应也变的越来越慢。

回顾

如果说从新来一次的话，有哪些可以改进的地方呢？

首先说数据表遗漏的问题，最近参加了一个培训，里面有一课讲的比较好，说的是自顶向下，意图编程，测试先行，与TDD类似。自顶向下是指从上层的语义开始而不是从数据表开始，因为上层的语义更加具有确定性，因此出错的几率更低，在真正需要的时候再来设计数据结构与表结构。再多说一次TDD，工作的这些年中发现没有一个团队在实行TDD的，可能是系统本身复杂度不够高，认为TDD开发效率不高，也可能是没有这方面的意识等。不过从我之前实践过的一个项目来看，效果还是不错的，一方面可以保证系统质量，更重要的是可以强制去更多的思考系统的结构，例如需要去进行接口的mock，这样设计出来的系统天然就具有更好的扩展性。

其次如何面对业务的变化，随着业务规则的不断变更，对系统之前的一些逻辑带来了挑战。在一些实践场景下可能就通过ifelse来叠加上去，导致系统越来越复杂。最近参加的培训中也谈到了这个问题，再加上之前内网中的文章结合来看，可以开始把应用层做厚，领域模型做薄，然后随着编码的深入，将确定性的逻辑移到领域中；当新规则打破之前的领域逻辑时，再进行重构去适应。

其他

回顾中的一些想法还并没有去实践，还需要一些项目去证实或证伪。