Multi-Scenario Business modeling System

Multi-Scenario Business Modeling System

Background

Before introducing the whole package, we must first introduce Ed is engaged in the Internet financial development, because our package design, indeed with the industry attributes have a close relationship, this package has been accumulated for more than 1 years, in the daily development process of our business has the following characteristics:

First of all, every month, there are almost a new scene of development work

60% of the demand in the new scene is the same, and 40% is not the same

Our products are broadly divided into applications, activation, lending, repayment of 4 large processes, each process is to provide data for different backend

The core problem is that everything is differentiated:

The differentiation of interactive vision: Every scene is always designed in a different place

Differentiation of the product flow: PM Sometimes adds some extra placements on some pages

Risk control Differentiation: here more elaboration, the core of financial lending is the wind control, did the financial development of the students must know that each scene needs to collect users what information, is determined by the wind control, for the final display of FE is the difference between visual and interactive, for PHP is the difference between each scene collection field, This is one of the key points of our design package.

Differentiation of third-party institutions: the information output by each agency is inconsistent, because the technical system is not in the scope of FE, this article does not introduce

Our aim: To improve development efficiency while improving our financial product management capabilities

Overall architecture Design

Last year to do a component of the program, this year has actually been doing platform integration work, first throw our overall architecture, the following will each module in detail, our business is divided into B-end and C-end, the B-terminal is a visual generation of differential configuration, the configuration file will eventually be placed inside the aconf module, The C-terminal is based on the aconf configuration file, the component or the modular generation page, the overall idea is like this:

This background color is currently the work of Fe (I do not know how to describe this color)

C-Terminal

Web front-end layer

Any new project team, the first thing FE needs to do is to be modular, the following diagram should be a clearer introduction to our work:

Web Application Layer

Last year because of the initial business, the overall project pressure is very large, and for the financial high-risk business, there can be no loss on the line, so our back end has been PHP.

Why we migrated node this year:

The first premise is that the company is currently in node framework, online operation, computer room disaster tolerance and so on this piece of support very good

Fe can be more familiar with the business, Better Business optimization: In fact, a lot of B-terminal related configuration work is actually FE own, but it requires PHP in the back-end support, this piece of the matter for PHP or FE are very bad

Save the overall manpower: for a new scene development, originally need 1fe+1php, now only need 1fe+0.5php

Reduce the cost of communication between FE and PHP: Because the coupling is heavier, the natural communication cost is higher, and now there is a public service, the equivalent of a more loose reliance, the cost of communication will naturally fall

Here are a few key points of our innovation:

We have divided the work of a new scene into public business and scenario business, the unification of public business is handled by FMS, and the personalized business is handled by different scene.

Fms

The FMS module contains all the public services, including several key points:

Multi-Versioning: This ensures that the public service is up-to-date and does not require all scenarios to be returned uniformly

Based on the configuration generated page, all the differences are reflected in the configuration (when the B-side will show the configuration of the visual page)

Component: For forms-filled pages, we are the component Configuration Generation page, which makes it more flexible

Modularity: For pages with standard business requirements, we generate pages in a modular configuration, which makes it easier to visualize the configuration, such as rich text editing similar configurations, which is best for modular generation

AXE

Axe is the public approach we've accumulated: Passport processing, tool methods, action base classes, RPC request encapsulation, uniform error code definitions, mock data, and more.

SCENE

Scene represents all of our scenes, and the scenario is also based on the public microservices development of the Axe public module and PHP.

Web services Layer

Because here is mainly PHP work, it is probably next, this layer is a public micro-service, according to our business needs to do a carding division, which is more trickery, we put the scene of service into the public service, follow-up there is no concept of PHP, not every time to develop new scenes, All need a scene PHP to pull a new module, so you can focus on all the power of PHP to do technical optimization.

B-Terminal

Web front-end layer

This package we can do, the core of all stems from: we have a system based on the Json-schema configuration to quickly generate the page (the company's internal system Amis), than any component of the program is almost fast, change at any time to take effect, first to the FEX students point