围绕业务订单进行的可扩展后台设计

围绕业务订单进行的可扩展后台设计

在互联网行业中,业务往往变化迅速,对于后台开发者来说,如何编写结构分明,逻辑清晰,能够进行快速扩展的代码是很重要的。
这里针对大多数系统都有的订单流转逻辑进行设计模式探索

业务订单的特点:

  • 业务处理多
    对于一个订单的处理,往往涉及到商户,余额,供应商,区域,黑白名单,商品库存等一系列逻辑。

  • 业务变化快
    随着业务量的上升,原来可能是做不了的业务,现在也能开放了;原来是定义为失败的订单现在又能在后台进行重试等等。

  • 业务可扩展
    原来订单只要处理完成就可以了,现在可能需要在订单处理之前对商户ip进行黑白名单鉴权;针对特殊业务可能需要特殊处理。

针对上面这些问题这里给出的解决方案是采用责任链的设计模式进行后台架构。

public interface Handler<REQ, RESP> {
    RESP handle(REQ req);
}
public abstract class AbstractHandler<REQ, RESP> implements Handler<REQ, RESP> {
    protected Handler<REQ, RESP> next;
    protected abstract RESP doHandle(REQ req);
    @Override
    public RESP handle(REQ req) {
        RESP resp = this.doHandle(req);
        if (null == resp)
            return resp;
        if (null != next ) 
            return next.handle(req);
        return resp;
    }

    public Handler<REQ, RESP> getNext() {
        return next;
    }

    public void setNext(Handler<REQ, RESP> next) {
        this.next = next;
    }
}

对于具体业务的处理者只需要继承该抽象处理器,并指定next处理器就可以将处理结果传递给next处理器。
从而完成整个订单处理。每一个具体的处理器只需要关心自己应该完成的任务,从而对业务过程进行了分解,而且整个逻辑也更清晰。当需要对业务处理扩展时,只需要单独添加具体的处理器,而不需要对其他处理器的逻辑进行修改,减少的冗余,耦合。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值