Taiwan trading system design and thinking

Foreword

Nearly two years, I have been a company in Taiwan to do research and development system, this may be the recent work experience may be ending. This article can be considered in the review and reflect on this experience.

system structure

Here is the main point of service access layer, in our current system architecture and there is no service access layer. But I reflect on the future, the service access layer that there is still very necessary.

Effect layer service access

  1. Coating effect. Because the business units within the enterprise to serve multiple business lines, daily development in response to different business needs, we often add a lot of conversion, interpretation logic in the underlying service, introduced a service access layer we can put this code access to the service layer.
  2. Business isolation. Each line of business within the enterprise has a unique scene of its business, and some call for service is relatively flat, and some businesses may focus on the outbreak at a certain time. As the table we do not want a certain scene or a bug caused all business operations are not available, it is possible for the access layer to limit the current business services (main program is the focus parameters Sentinal limiting).
  3. Easy to manage external output capability. Developers only need to write and maintain documentation of the interface documentation for interface access layer in the subsequent development. Secondly, the entire developer in Taiwan as long as the external output of the access layer to understand those capabilities can have a cognitive ability in overall table, not face many of each underlying service interface.

Highlights trading in Taiwan

In the construction trades station, or a major design business in Taiwan actually two things:

  1. How to provide reasonable access procedure available to the business side. Let the business side of the full implementation of their business while being able to quickly access
  2. How to deal with differences in the Taiwan business systems for different business processes on business

Access Process

Into the main flow of FIG access:


In the front page the user to purchase goods. Then call the business side of the interface, to submit information and other services purchased party call station interface to create a single transaction, the transaction order number and get themselves associated with business data, and then evoke universal payment component of the transaction order number.
Arouse payment component to pay for this party do not care about business logic, payment component? Interact directly with the Taiwan deal.
After successful payment, transaction processing orders logic units, handling the business side after completion callback, then the business side business logic based on a single transaction processing callback number itself.

Access procedure in the design and evolution actually encountered some problems:
initially created in the first step of the business side is not visible orders data, which also caused a large number of invalid orders data transaction systems, and later optimized to trading orders, order number multiplexed single transaction number, which is transparent to the business side in fact no effect.
There is a payment processing business side callback and callback this step, initially synchronous call, which also caused a reverse flow of the business side of the system depends on order status, when the business side of the system fails, order status can not be normal circulation.

Differences in business

The following two service as an example, I just described about the processes, business process on the real may be more complex.

When the elimination of differences in business, we must first analyze the various business processes, identify the most complex business as a sample, which is a general-purpose logic analysis, which is the logic there is a difference.
Examples of the mall is probably the most complex process, members of the process is simpler. According to the figure we can persist in the order data nodes into two flow difference,
pre-processing before the order persistent, post-processing after the persistence order.
We form a single component for logic functions to pull away, and pre-processing and post-processing to create different components according to the call chain business.
Here is sample code:
We first define the component

public interface Processor<T, R> {
    /**
     * 执行内容 ,中断抛出{@link com.xxx.xxx.infrastructure.exception.ProcessorInterruptedException}
     *
     * @param context
     * @param result
     */
    void process(T context, R result);

    /**
     * 触发调用下一个 Processor
     *
     * @param context
     * @param result
     */
    void fireNext(T context, R result);

    /**
     * 检查是否执行该 Processor
     *
     * @param context
     * @param result
     * @return
     */
    boolean check(T context, R result);
}

public abstract class AbstractProcessor<T, R> implements Processor<T, R> {
    private AbstractProcessor<T, R> next = null;

    public AbstractProcessor<T, R> getNext() {
        return next;
    }

    @Override
    public boolean check(T context, R result) {
        return true;
    }

    public void setNext(AbstractProcessor<T, R> next) {
        this.next = next;
    }

    public void invoke(T context, R result) {
        try {
            process(context, result);
            fireNext(context, result);
        } catch (ProcessorInterruptedException ex) {
            return;
        } catch (Exception ex) {
            log.error(ex.getMessage(), ex);
            throw ex;
        }
    }

    @Override
    public void fireNext(T context, R result) {
        if (next != null) {
            if (check(context, result)) {
                next.invoke(context, result);
            } else {
                if (next.getNext() != null) {
                    next.getNext().invoke(context, result);
                }
            }
        }
    }
}

Construction assembly then define abstract class chain

public abstract class AbstractProcessorBuilder<T, R> {
    @Autowired
    protected AutowireCapableBeanFactory autowireCapableBeanFactory;
    protected AbstractProcessor<T, R> instance;

    @PostConstruct
    public void init() {
        initProcessor();
    }

    public abstract void initProcessor();

    public AbstractProcessor<T, R> build() {
        return instance;
    }

    public void addLast(AbstractProcessor<T, R> processor) {
        if (instance == null) {
            instance = autowired(processor);
            return;
        }
        AbstractProcessor<T, R> next = instance;
        while (next.getNext() != null) {
            next = next.getNext();
        }
        next.setNext(autowired(processor));

    }

    protected AbstractProcessor<T, R> autowired(AbstractProcessor<T, R> processor) {
        autowireCapableBeanFactory.autowireBean(processor);
        return processor;
    }
}

Pre-call chain business for the above two

@Component
public class StoreSubmitPreProcessorBuilder extends AbstractProcessorBuilder<SubmitOrderContext, ResultDTO<SubmitOrderResult>> {
    @Override
    public void initProcessor() {
        addLast(new CheckSubmitOrderNumProcessor());
        addLast(new CheckItemBuyNumLimitProcessor());
        addLast(new PaddingAddressProcessor());
        addLast(new CheckDeliveryLimitProcessor());
        addLast(new QuerySkuProcessor());
        addLast(new CheckSkuProcessor());
        addLast(new CalPromotionProcessor());
    }
}


@Component
public class PrimeSubmitPreProcessorBuilder extends AbstractProcessorBuilder<SubmitOrderContext, ResultDTO<SubmitOrderResult>> {
    @Override
    public void initProcessor() {
        addLast(new QuerySkuProcessor());
        addLast(new CheckSkuProcessor());
        addLast(new CalPromotionProcessor());
    }
}

Simplify the submission of the order code:

        getSubmitPreProcessorBuilder(bizType).build().invoke(context, ret);
         if (!ret.isOk()) {
                return ret;
         }
         //.....

Through this component of the way, we can get a different ProcessorBuilder according to different business processes to deal with differences.

Thinking station

In Taiwan provide not only interface components so simple, management background such as trading in Taiwan, also need to provide the order, the order data visualization, through capacity in Taiwan continue to strengthen, to make the front office to focus more on their business.

Taiwan's ability to provide ongoing promotion, when the demand raised by a single business sense, as in the realization of its success stories can be generalized to other businesses, so that other businesses enjoy the dividends of the station building, the only constant promotion, continued feedback capability in Taiwan will be stronger.

Taiwan is not only in business architecture, but also an organizational framework, only independent organization to ensure that resources are not inclined to generate some business.

In Taiwan to build according to the actual situation of enterprises, a clear view is willing to solve the problem of the corresponding companies.

Tips: hereinafter also with reference to exemplary service business Jingdong sample, the sample code is also a modification of the actual code

Guess you like

Origin www.cnblogs.com/javanoob/p/trade_middle-platform_design.html