1.不符合一对上下游系统的设计要求，但适合当下业务场景的需求。 下游积分核心系统设计上不该持有事件和渠道字段，因为它不该去关心上游业务，事件或渠道与对应积分明细的关联应该由上游系统来维护，或则在上游系统和积分系统之间再加一层积分系统的业务层，用于维护这层关系（关于易复用性的中台思想）。当下的业务场景，积分的管理系统是有必要维护一份 事件渠道的值对象的。因为带有这个值对象，积分系统管理员才能不需要再多个系统中寻找积分增减关系，进而可以独立满足管理积分这件事的整个业务域。（事件和渠道只能作为值对象冗余在积分系统）。

2.不符合单一职责的限制，但满足当前业务场景的诉求。该接口做了增减积分和返回积分id两件事，且语义上并没有返回积分id的相关字眼，所以方法名定义也不明确。但是上游系统在变更积分后，需要获取积分id以作为上游系统变更事件与积分记录的关联key。而这个key只有在当前变更操作获得，所以就只能写这种语义不明且违反单一职责的方法。（让我来设计，我会把积分id的生成作为积分系统的一个外放接口，上游业务调用该接口获取id，记录关联关系，然后走mq推积分系统实现最终扣减。这样就可以规避上述这种无奈的场景）。

针对争哥的第一个问题，从设计角度来说不应该记录渠道和事件。从业务来说，必须记录交易的渠道和事件。基于这种妥协可以设计一张表。那是否也可以设计两张表？

积分交易表和明细表：
1、credit_transaction
trans_id
user_id
channel_id
event_id
create_time
2、积分明细表credit_detail，只记录积分加减
trans_id
credit (积分加减)
create_time
expire_time

第一次评论说的不对请指正

第一个问题分两种情况：
1. 如果是积分和营销业务分离的话，下层业务就不应该关注上层业务，积分系统只记录自己的流水，event_id和channel_id则应该由上层记录
2. 如果是积分和业务系统放在一起的话（就像争哥推荐的那样），这种方案就符合当前业务情景。

第二个问题：
这种虽不符合单一职责，但如果每次插入后业务需要ID的做其他事情的话（或者以后也需要），这种方案的成本最小。