多情境業務建模系統

                                             多情境業務建模系統

背景

在介紹整套方案之前，一定先要介紹ED目前是從事的是互連網金融開發，因為我們的整套方案設計，確實跟行業屬性有密切的關係，這套方案大概已經積累了1年多了，在日常開發過程中我們的業務有如下特點：

首先每個月幾乎都有新情境的開發工作

新情境中有60%的需求是一樣的，也有40%是不太一樣的

我們的產品大致分為申請、啟用、放款、還款4大流程，每個流程都是給不同的後端提供資料

核心問題如下，一切皆是差異化：

互動視覺的差異化：每個情境在設計上總是一些不太相同的地方

產品流程的差異化：PM有時候會在某些頁面上添加一些額外的展示位

風險控制的差異化：這裡多闡述下，金融放貸的核心就是風控，做過金融開發的同學肯定知道，每個情境需要收集使用者哪些資訊，都是由風控來決定的，對於FE最後表現出來的就是視覺和互動上的差異，對於PHP就是每個情境收集欄位的差異，這也是我們整套設計方案重點之一

第三方機構的差異化：每個機構輸出的資訊不一致，由於技術體系不在FE的範疇，本文不介紹

我們的目的：提升開發效率的同時提升我們金融產品管理能力

整體架構設計

去年做了半年的組件化方案，今年其實一直在做平台一體化的工作，先拋出咱整體的架構，後面會每個模組詳細闡述下，我們的業務主要分成B端和C端，B端是可視化的產生差異化配置，這個設定檔最終會放在Aconf模組裡面，C端基於Aconf設定檔，組件化或者模組化產生頁面，整體的思路大概是這樣子：

這個背景顏色的目前都是FE的工作（實在不知道這個顏色怎麼描述）

C端

Web前端層

任何新成立的項目組，FE需要做的第一件事情應該都是組件化，下面這個圖應該會比較清晰的介紹我們工作：

web應用程式層

去年因為業務初期，整體項目壓力非常大，而且對於金融這種高風險業務，線上是不能有任何損失的，所以當時我們的後端一直是PHP。

今年我們為什麼遷移Node：

首要的前提就是公司目前在Node架構、線上營運、機房容災等這塊支援非常好

FE能更熟悉業務，更好的最佳化業務：其實很多B端相關的配置工作其實都是FE自己的，但是卻需要PHP在後端支援下，這塊不管事對PHP還是FE都非常的不好

節省整體的人力：對於一個新情境的開發，原來需要1FE+1PHP，現在只需要1FE+0.5PHP

減少FE和PHP的溝通成本：原來因為相互耦合更重，自然溝通成本更高，現在有了公用服務，相當於依賴更加鬆散了，溝通成本自然會下降

下面說下，我們創新的幾個核心關鍵點：

我們將一個新情境的工作分成了公用業務和情境業務，公用業務統一都由FMS來處理，對於個人化的業務都由不同的SCENE來處理

FMS

FMS模組裡麵包含了所有的公用業務，其中有幾個關鍵點：

多版本控制：這樣可以保證公用業務的上線修改，不需要所有情境都統一迴歸

基於配置產生頁面，一切差異化都體現在配置裡面（講B端的時候會展示配置的可視化頁面）

組件化：對於表單填寫類的頁面，我們都是組件化配置產生頁面，這樣可以更加靈活

模組化：對於業務需求比較標準的頁面，我們就以模組化配置產生頁面，這樣更加方便可視化配置，比如富文本編輯類似的配置，這個最好還是模組化產生

AXE

Axe是我們積累下來的公用方法：包括了passport處理、工具方法、action基類、RPC請求封裝、統一的錯誤碼定義、mock資料等。

SCENE

SCENE代表了我們所有的情境，情境也是基於Axe公用模組和PHP的公用微服務開發。

Web服務層

因為這裡主要是PHP的工作，就大概說下，這層是一個公用的微服務，根據我們的業務需求做了梳理劃分，這裡面比較取巧的是，我們將情境的服務放到了公用服務裡，後續也就沒有了情境PHP的概念，不用每次開發新情境的時候，都需要情境PHP去拉一個新的模組，這樣可以更加集中所有PHP的力量做技術最佳化。

B端

Web前端層

這套方案我們能這麼搞，一切的核心都源於：我們有一套基於json-schema配置快速產生頁面的系統（公司內部系統Amis），比任何組件化方案都快要快都要好，隨時改隨時生效，先給FEX的同學點個