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

**有会员卡时：**     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

  只管支付 库存另外系统