免責事項：
この記事はブロガーオリジナル記事ですが、許可ブロガーなく再生してはなりません。いかなる社会的関心の技術交流（ID：jishuhui_2015）は、著者にリンクすることはできません。
コアバウチャーシステムは、管理、流通及び使用の様々な結合タイプのことです。
デザインビューのエンドユーザのポイント、いわゆる「WYSIWYG」から通常、エンドユーザーは、チャレンジは、システム全体の開発であるクーポンのすべての種類を見てきました。
オンラインとオフラインの活動の異なる形式に応えるためには、想像して、クーポンシステムは大幅な変更を持っているにバインドされ、変更のコストの削減を最大化する方法を、挑戦の中核となりました。
上記の問題の観点から、溶液は：ルールの実装および単離されました。
あるルール層は、達成することができるだけでなく、クーポンの様々なタイプの使用を制限します。
ルールに従って計算実行層は、最終的な販売価格として理解することができます。
ルール層のために、私はそのルールエンジン、唯一の適切な抽象化の高さに上昇する必要はありません。また、市場ルールエンジン開発フレームワークは、この複雑なアプリケーションシナリオのクーポンを満たすことができないかもしれません。
これは、クーポンはプロモーション活動のいずれかの形式と同等ではないことは注目に値するが、それは全体的なマーケティングシステムの一部です。さらに困難システムを実現するためのクーポン、プロモーション活動に比べて。この記事は、この記事の範囲のクーポンシステム、設計と実装の開発が推進されていないどのように説明することを意図しています。
まず、どのようにクーポンを生成します
クーポンを生成する前に、我々は最初のを見て、「クーポンテンプレート」のコンセプト。
名前が示すように、テンプレートによれば、クーポンを生成します。
工業生産ライン上のカビのように、単に加工用原料を注入し、それが最終製品にすることができます。
そのため、テンプレートは、クーポンに関連する多くの情報を運ぶ含むが、名前、適時に限定されるものではなく、優先ルールだけでなく、クーポンや他の宗派のすべての種類は、テンプレート自体は、タイトル、ステータス、基本的な情報や、他の人が作成しています。
あなたはテンプレートのセットを指定して、生成する準備ができクーポンの合計数を記入されたクーポンを、生成する必要がある場合には一部にも、クーポン、指定した受信者を生成し、バウチャーは、操作の完了と一緒に配布されることができます。
助けることは、読者尋ねることができませんでした。この設計は不要であると思われるが、クーポンやバウチャーエンティティテンプレートは、なぜ直接クーポンも生成されたチケット・テンプレートの一部を省略しない、重複の多くを属性？
これには2つの理由があります。
まず、運用スタッフの効率を向上させることができ、限り、テンプレート情報として、バッチ・チケット生成を達成することができ、再びそれを入力し、同じクーポン情報を繰り返し入力する必要はありません。
第二に、テンプレートを作成し、クーポン券エンティティを送信完了するための異なる権限を持つ人々の2種類があります。高い権限の運用スタッフは、テンプレートを作成する権利を保持することができるかもしれない、通常の運用スタッフはテンプレートに従ってクーポンを送信する必要があります。
以下に示すように、バウチャーやクーポンテンプレートエンティティ間の関係を反映しています：
設計の第二に、優先ルール
図は、基本的には明確な、そして私たちは、優先ルールの設計に焦点を当てることができ、コンテンツに関連します。
優先ルールは間違いなくクーポンシステムの中核であり、どれだけ優先ルールの実装を参照して、運用上のニーズを最大限にするために、市場に適応することはできません。
明らかに、市場の優先ルールを達成するために、徹底的な方法では賢明ではありません。
いわゆる私たちは、自然の優先ルールを抽出するためにしなければならない「世界で唯一の定数は変化がある」「現状維持します」。
ビジネスニーズと組み合わせ、研究の一般的な市場優先規則の著者は、優先ルールは、大きく分けて2つのカテゴリに分けることができます。
1、計算ルール。ユーザーが計算され、このクーポンに参加する方法を知っているように、これらのルールは、エンドユーザーに公開されているなど、「しきい値なしまっすぐに20元、」「フルカットのXX XX」、のような形、それは、明らかです。
2、制限のルール。計算規則と比較すると、ほとんどの場合、制限的規則の下で、それは劣性です。例えば：、受け取るために特定のユーザーを制限し、クーポンやその他の制限チャネルを支払うことができますどのくらいのお金までテンプレートクーポンクーポンの特定のセットを制限します。このような規則は、日常業務が動作し、非常に良いサポートすることができます。
「すべてアレロパシー」、優先ルールの多くは、それが共存することはできない、どこの導入に関する規則「相互に排他的」という概念。優先ルールと優先ルールが同じ時間に、テンプレートの別のセットに存在しない場合は、我々はまた、ルールを設計する際に検討する必要がある、これらの二つのルールは相互に排他的であると考えています。
其次，优惠规则也会讲究先后顺序，所以必然就带来了一个优惠规则的『优先级』属性，我们约定，数字越小，表示越优先，也就是按从小到大的顺序。
以下给出一张完整的规则表，信息量较大，笔者将做必要的解释。
规则表中，渠道限制、对象限制、金额限制和数量限制四者皆属于限制型规则，优先级排在了较前面。同时，也给出了参数说明，规则描述，相对于模板的关系以及互斥规则，这些都是一目了然的。
接下来的扣减规则和封顶规则同属于计算型规则，也算是优惠券的重中之重了。
笔者着重解释一下满减规则中的“阶梯满减”。我们平常会看到有这类说法：每满100元减10元，言下之意便是：满100元减10元，满200减20，以此类推，笔者将其称之为“阶梯满减”规则。
三、优惠规则编号的设计
规则表中有涉及好多数字，笔者设计了一套生成规则。
规则编号是int型，Java 编程语言中，int全长 32位，如下图所示：
1、第一位是符号位，固定为0，且不允许出现 32位全是0的情况，即为正整数；
2、高8位是规则组别编号，理论上允许的数值范围是0~255，但是实际的业务规则是假设最多有15组优惠规则，每组优惠规则编号取10的倍数，范围即为 10~150；
3、第10位和11位作为备用，暂无实际用处，固定为00；
4、中间15位，存放规则组下的细则编号，允许的范围0~32767，但是实际业务规则是要达到两两互斥的目的，取值如下(以四位二进制为例)：
0001
0010
0100
1000
结论：排除全为0的情况，那么有N位，就有N组两两互斥。如果组内组外互斥都考虑，那么可取值就更少了；
5、末6位存放规则组的优先级，允许的值范围是0~63，实际取值从1开始，考虑到之后会插入其他的规则组，会在每两个规则组别直接预留两个级别，初始的优先级设置为1，4，7，10，13，16…；
6、按照上述规则，根据既定的组别和优先级可以生成上表中的细则编号。
渠道限制 83888577
0 00001010 00 000000000100111 000001
用户类型限制 167775300
0 00010100 00 000000000110001 000100
指定用户限制 167776900
0 00010100 00 000000001001010 000100
总金额限制 251660487
0 00011110 00 000000000100011 000111
单位金额限制 251662535
0 00011110 00 000000001000011 000111
总量限制 335545290
0 00101000 00 000000000001111 001010
个人所获限制 335544778
0 00101000 00 000000000000111 001010
无门槛直减 419430989
0 00110010 00 000000000001001 001101
满减 419431565
0 00110010 00 000000000010010 001101
打折 419436813
0 00110010 00 000000001100100 001101
封顶规则 503323024
0 00111100 00 000000001100110 010000
四、优惠券系统程序设计
在做程序设计之前，我们必须把握住关于优惠券的三个主要动作：
1、管理。指的是对券模板的创建，规则设置，关闭等操作。当然，在给模板设置规则参数的时候，需要校验规则参数的合理性。
2、派发/领取。笔者将这两个操作进行了合并，两者的区别无非就是有没有绑定终端用户，在接口层面是可以合并的。通常，限制型规则会在此发挥作用，当触发了这两个操作的其中一个，在生成优惠券之前都将会先用限制型规则进行校验。
3、使用。就是将优惠券花出去，计算型规则会在此发挥作用，主要是判断满不满足券的使用条件，计算减免金额等。
综上，程序设计就靠这三个动作进行延展。
我们先来设计一下规则层。
根据规则表中定义的一系列规则，反映在程序中可以有两种形式：
一种是使用配置文件（通常是XML），然后程序去解析；
另一种则是直接使用枚举类（或者其他形式的类）。
第一种开发难度稍大，想做得比较强大的话，是需要花费不少功夫的。
对于优惠规则的定义和实现都是事先内置在程序中的，并不是非专业人员改变一下配置文件就能达到效果的。
所以基于此考虑，使用了第二种实现方式。如下所示即为规则定义：
Rulers含有五种重要的属性：规则编号（ruleNo），规则名称（ruleName），排序（sort），对应的Model Class对象，以及实现特定接口的serviceName。
接下来的三个方法也较为重要：通过规则编号直接找到对应的枚举，判断是否是计算型规则，规则是否有多参数，和券模板是1~*的关系就表示是多参数。
当然，也少不了持久化到数据库的各类Beans，每个Bean都会继承一个叫作SuperRule的抽象类，子类的属性都是规则表中提及到的。Rulers中的Model Class就是来自于此。由于规则较多，下面只展示SuperRule：
我们再来看看Service的定义：
最顶层的BaseRuleService是规则基本的CRUD操作，使用了泛型R，继承自SuperRule。BaseRuleService有一个抽象实现，除了泛型R，还有一个Mapper（Mybatis）。
因为将规则分成了两大类，自然而然的就能派生出两个Service，分别对应计算型规则和限制型规则。
最后一个是对规则参数的校验，使用了泛型R，继承自SuperRule。
制限ルールの両方が存在する可能性があるため、上記の3つのサービスを（達成するまでこれまでのところ、インターフェイスのデザインは、もし新しいルールが表示されることを意味し、上記3つのクーポン関連の操作を含むようにし、 ）計算ルールですが、ほとんどの場合のように長い2つのサービスの実現として、その後、ルーラに新しいルールを設定します。基本的なCRUD操作のルールについては、限り相続AbstractCouponRuleServiceとして、あなたが達成するために余分な労力を費やす必要はありません。
だから、多くのルールは、自然に必要な「クラスファクトリ」などのルールBeanインスタンスを作成すると、スケジューリングのために、サービスのインスタンスを生成します。
V.の概要
ビジネス設計からプログラミングまで、クーポンシステムに、より包括的かつ明確な博覧会を行うには、読者がちょうどバウチャーシステムを開発する必要がある場合は、この記事では良い参考になります。
