浅析：通过自定义DSL实现一个序列号生成器

原始文章首发于个人博客

一、什么是DSL

DSL是（Domain Specified Language）的简称，中文含义为：领域专用语言。
设计者通过特定的语义，描述一些在特定的应用场景中出现的东西。

二、为什么要使用DSL

设计并使用DSL的优势在于：在解决特定问题时，有更简洁、更强大的语义表达能力。可以使用更少的代码（或配置）来描述问题，开发效率高。

我们在日常工作中，往往会在大量重复性的工作上浪费大量时间。针对这种共性很强的工作，我们设计一个具有通用性和简洁性的描述性语言，可以减轻我们的工作负担，也可以使项目代码更简洁易读。

三、分析业务需求

在公司内部系统开发中，有一个这样的需求：

需要设计一个序列号生成器，它能放在不同模块代码中，根据不同模块的序列号生成规则生成序列号。

通过分析生成规则，发现序列号生成器需要包含的功能有：

1. 在不同业务模块中生成的模块CODE不一样
2. 需要包含当前日期。但生成的日期格式每个模块可能会不一样。（有的是yyyy-MM-dd，有的是yyyyMMdd等）
3. 需要生成流水号。流水号各个模块需要生成的位数可能不一样，有的需要定长4位，有的需要定长3位。位数不足的有的需要左补0（或者左补其他符号）

四、DSL设计

通过上述的需求分析，我们不难看出：

1. 各个业务模块的序列号生成策略有一定的共性：比如都可能包含：日期、流水号等
2. 序列号生成策略中的变量仅有：模块编码、日期、流水号这三项，且业务模块对于流水号的需求仅定长不同

综上所述，便有了2种解决思路：

1. 设计一个序列号生成工厂组件，提供：模块编码、日期、流水号等生成策略选项，由开发人员在实际开发过程中自己调用相关方法，按需使用。
2. 考虑到每个模块都对应一个唯一的模块编码（模块编码要有，但是可以不作为生成序列号的一部分被显示），因此可以将业务模块和对应的模块编码相绑定。然后再利用注解，在对应的模块编码上指定相应的生成策略。

第一种“手动指定策略”的思路我们先不详细说。这里来详细说说第二种思路。

1. 先将各个业务模块对应的模块编码梳理出来，整理成一个配置类
2. 在配置类中的模块编码上，使用注解指定该模块对应的序列号生成规则
3. 打算使用类似于EL表达式中取值的方式（即：类似于：$xxx的方式）（注：后续代码中为了方便，直接用了的方式来取值，就没有写$了）来实时计算并填充数据
4. 将计算出来的序列号返回

因为在业务需求中只有4个变量，所以我们首先得给那4个变量起个名字：
例如：

• 模块编码可以使用： ${module_code}来表示
• 日期可以使用：${date}来表示
  等等…

五、详细代码设计

• 首先准备一个配置类，将梳理好的模块编码都放进去
  
• 使用自定义注解指定序列号生成策略
  

如上图所示，电脑前有新的同学肯定已经发现了：里面还内嵌了一个@Appender注解。啥是@Appender注解？
@Appender注解定义长这样：

这是因为考虑到后期的代码扩展性，我将流水号生成的策略（占几位，补什么符号等）抽离出来，使用@Appender注解可以起到灵活配置的作用。

• 写一个脚本解析器，用于解析注解中的序列号生成策略

1. 首先读取注解内容
   

2. 计算或获取实际内容，然后替换掉生成策略脚本中对应的变量占位符
   （注：为了精细化控制日期显示格式，所以在代码中用了多种日期格式变量）
   

字符替换方法详情：

六、总结

上面只是简单地谈一谈一种基于自定义DSL，结合注解形式来写一个序列号生成器地思路。还有很多细枝末节的东西没有说到，例如：

• 如何保证每天生成的流水号从1开始顺序累加？ --redis或其他分布式锁机制
• 如何用最短代码将多个模块共用同一套生成策略？
• 如何同时集成“自动生成”和“手动生成”两种方式？

如果展开说那又可以水一篇博文了，这篇文章主要说一下思路，也算是给自己做一个经验累积~