请教各位大佬，在开发收银终端结账功能时，有啥好的开发逻辑/架构思路吗？

[tohert]

结账功能大概涉及以下功能：

**有会员卡时：**
    1.商品可使用积分抵扣单价，购买完成可以得到积分
    2.商品除零售价外有会员价 /会员折扣
    3.可使用会员卡结账
    
 **无会员卡时：**
    1.可使用现金、扫码（在线）支付
    
 **结账时：**
     1.增加出库记录，修改商品实时库存
     2.可多种支付方式支付
     3.修改会员卡的当前积分和当前余额（如果使用会员卡）
     4.增加会员积分记录和余额记录（如果使用会员卡）
     5.如果扫码支付时，可能会存在用户输入支付密码（可能取消支付）情况， 这种不是实时的支付结果可能会导致整单取消

在开发前，功能大概都了解，觉得开发难度还好。但是做起来战战兢兢，不知道如何设计代码功能，只能那种代码一把梭，太冗余太臃肿了，感觉自己写的很糟。 有大佬能指点一下怎么去设计这个功能吗？ 或者有类似的开源代码让我去啃？感觉自己太菜了，只能做简单的增删改查了现在。

[zoharSoul]

我只清楚支付服务的设计.
**有会员卡时：**
1.商品可使用积分抵扣单价，购买完成可以得到积分
2.商品除零售价外有会员价 /会员折扣
3.可使用会员卡结账

对于支付服务来说,这些统统不管,统一作为交易配置来处理,交易时去获取,生成订单金额,优惠金额,支付金额.

**结账时：**
1.增加出库记录，修改商品实时库存
2.可多种支付方式支付
3.修改会员卡的当前积分和当前余额（如果使用会员卡）
4.增加会员积分记录和余额记录（如果使用会员卡）
5.如果扫码支付时，可能会存在用户输入支付密码（可能取消支付）情况， 这种不是实时的支付结果可能会导致整单

库存什么的统统不管,处理好商家余额和订单 /流水的事务一致即可.
其他乱七八糟的玩意统统用 kafka 把消息丢出去让外围业务自行消费.

[zoharSoul]

交易系统只负责维护商户余额,订单,流水 这三个核心表.

[zoharSoul]

也就是对于交易 /服务来说.
他不清楚也不关心,什么会员卡之类的东西,那是在下单前要确定的.
具体要向 三方支付平台 生成多少钱的订单来拉起付款界面,这是外围告诉交易服务的..

[yiyi11]

没事，写就完事了，多测试。

[wmhx]

只要账不乱, 钱不乱, 就可以慢慢来.

[tohert]

@zoharSoul
所以说，我可以思考把这些功能都拆开，然后一根主线把所有功能关联起来 ？
现在是有一点点头绪，因为写完之后再来回看之前写的代码，好多重复的。 但是还是没法下手，看着就前几天写的代码就头皮发麻。。。

[tohert]

@yiyi11
唉， 测试肯定是要测试。只是回看那些代码很会让人抓狂。 之前看过大话设计模式，发现在现实的写代码过程中，没有那种设计模式的代入感。这个让自己感到很迷

[tohert]

@wmhx
能保证帐不乱，钱不乱已经很好了。 我现在是有点对自己的代码没信息。:speak_no_evil:

[namelosw]

@tohert 这个不是设计模式级别的东西，是架构方面的东西。

基本上核心就在拆分不同的上下文，让它们之间有边界，交易和库存一般是两个完全分离的东西，偶尔有交互的话互相调用。比如会员可能是个单独的东西，也可能不是，也可能太简单就可以合并到其他的上下文里面。还有比如记录这种假如拆出去就单纯地消费其他的上下文。

经验不多的话可以尽量少拆，还是写到一起，代码会乱一些。因为拆过头一般初期比拆少了难处理，还有一些一致性问题拆完了就很难搞。
代码层面，如果放到一起太乱也可以试试有限状态机之类的缓解一下。

[zoharSoul]

@tohert
先不要急着写,
先写好技术方案,做下技术评审听听大家意见.

一个模块一个模块的梳理过去, 支付相关的模块独立性都比较强反正

[tohert]

@namelosw
嗯，现在是不敢拆。 但是自己看着代码难受，总想做点什么。 可能 CRUD 做的太多，自己还是太弱了。 多谢解答。

[tohert]

@zoharSoul
嗯，现在是自己在开发环境慢慢改，线上的不敢去覆盖。0.0
主要还是自己太弱了吧。
多谢解答啦。

[kiracyan]

只管支付 库存另外系统