扩展字段——编程心法（二）

难度等级：玄阶中级

适用场景

扩展字段一般出现在实体的建模过程中，多用于对一个“不稳定”实体的建模。”不稳定”表示对这个实体的认知目前还不清楚，并不确定该属性是不是属于实体。

举几个例子：

在行列转化——编程心法（一）的Story-4中，小明设计了rule_1 rule_2 rule_3三个字段，这三个字段都属于扩展字段。这个阶段小明不确定Rule是否真的属于Lottery，但又不想过度设计，此时采用扩展字段的方式既能解决问题，改动内容有比较少。
在公有云的订单系统中，经常会出现下单时选择”到期自动续费/删除“的选项，但不是所有的产品都有类似的选项。当时，我们在订单系统中设计一个ExtraParams来存放这些附加参数。对于”到期自动续费/删除“这个需求，当时我们很难判别它是订单的必须属性还是演进过程中的一个临时需求，此时采用扩展字段的方式是合适。

扩展字段一定不是实体的必要属性。实体的必要属性在建模时就应该能清晰地辨识出来，而扩展字段对构成一个基本实体并不会产生较大的影响。随着实体的演化，扩展字段时有可能转化为实体的必要属性的。
不要滥用扩展字段。如果你能尽早的确定扩展字段的意义，那么就应该使用更有意义的描述词汇，而不是Extra Params之类的通用词汇。更加具象的词汇能更加清晰地反映你对模型的认识。

尽量不要使用扩展字段。正如前面所说，使用扩展字段正是源于我们对实体模型认识还不清晰，如果你准确的知道该字段的意义，那么就不应该使用扩展字段。
扩展字段不要太多。个人建议不要超过3个，如果超过这个值，可以参考行列转化——编程心法（一）的技巧将模型进一步拆分。
扩展字段的内容尽量简单。不要再扩展字段里面承载太多的内容，如前面所说的”到期自动续费/删除“、一个规则的参数等。如果在扩展字段里面承载过多的内容，往往意味着这里的模型设计存在某些问题，我们需要重新思考字段内容与实体间的关系。

扩展字段时常会和类型字段一同出现，如行列转换的Story-5中，规则(Rule)已经转化为了一条条具体的行。但是规则所需要的参数往往是动态的，例如我们需要对XXXPay的信誉值在(a,b)的用户做活动，而积分值要大于1000。那么规则表的设计如下：

id	type	param_1	param_2
1	XXXPayRule	a	b
2	PointRule	1000	-

param_1和param_2就属于扩展字段，他们针对不同的type有则完全不同的意义。

扩展字段在我们还对实体的某些属性还不清楚时是有帮助的。但从实体的整个演化周期来看，扩展字段是一种临时的过度手段，它会增加我们地技术债务。