背景

參加了阿里系的一次電面，面試官最后留了題，讓幫設(shè)計(jì)一個(gè)消費(fèi)貸系統(tǒng)。
要求是：

通過u酷或者 ucweb 作為流量介入 使用銀行作為渠道 在銀行和流量之間做一個(gè)系統(tǒng)
承載留存 分潤 數(shù)據(jù) 流程 和風(fēng)控

解題

其實(shí)還是比較喜歡這種類型的面試，出題型，以前一般是在外企面試才會(huì)遇到，就是留一個(gè)題和限定時(shí)間給你，一般一周內(nèi)，能解決就錄取。個(gè)人感覺比面試的時(shí)候問一堆概念和方法論靠譜一點(diǎn)。
但這個(gè)題比較抽象，做過開發(fā)的人都知道這種需求沒法做設(shè)計(jì)，這種需求如果是技術(shù)TL或者產(chǎn)品經(jīng)理給出的話，開發(fā)已經(jīng)已經(jīng)內(nèi)心崩潰了吧。但是如果是甲方爸爸給出的，就只能盡可能的自我合理化...畢竟是爸爸。
好歹我也接過一些甲方需求，就用對(duì)待甲方的態(tài)度對(duì)待這個(gè)題吧。

需求拆解

甲方有時(shí)候不知道自己要什么？只知道一個(gè)方向：就是引流給銀行，銀行下款之后分利潤，這個(gè)大方向。技術(shù)需要按照可落地的方式進(jìn)行需求拆解。

1 拆解這個(gè)需求中的用戶

這個(gè)系統(tǒng)是一個(gè)toBtoC的系統(tǒng)，通過服務(wù)B端，觸及C端，技術(shù)服務(wù)方是阿里系的這個(gè)公司。系統(tǒng)用戶有幾個(gè)類別：

• 借款用戶，C端用戶
• 用戶渠道，流量來源，UCweb和u酷
• 資金渠道，銀行

C端：需要解決的訴求是，多，快，好，省。
用戶渠道：快速接入，低成本接入，快速上線和下線。
銀行：流程管理，資金安全，結(jié)算精確。

這個(gè)系統(tǒng)需要兼顧這三種用戶的差異和不同的訴求。

• C端用戶給出用戶選擇，統(tǒng)一各個(gè)銀行貸款產(chǎn)品的利率計(jì)算方式和材料，有個(gè)很好的展示和流暢的體驗(yàn)，通過算法解決篩選，推薦和功能上提供，資料復(fù)用和進(jìn)度查詢。
• 渠道用戶提供H5兩個(gè)接入方式，無需渠道投入開發(fā)，以H5活動(dòng)頁面方式接入移動(dòng)端和渠道端，同時(shí)提供管理工具，便于快速記錄渠道來源，數(shù)據(jù)統(tǒng)計(jì)，頁面上線和下線。輔助提供api或者SDK的接入方式，便于渠道根據(jù)自己的技術(shù)棧來選擇。
• 銀行端：默認(rèn)銀行的開發(fā)流程長，所以系統(tǒng)層面需要幫助銀行設(shè)計(jì)一個(gè)管理系統(tǒng)，接入銀行內(nèi)部的系統(tǒng)，內(nèi)網(wǎng)部署，比如：額外設(shè)計(jì)一個(gè)OA系統(tǒng)，或者其他內(nèi)部管理系統(tǒng)，便于銀行根據(jù)多身份多權(quán)限的管理，處理銀行的用戶注冊，貸后審核，風(fēng)控，審記，還款等全流程的審批和管理。

2 拆解這個(gè)需求中的信息流（資金流）

身份已經(jīng)不用說了，資金流向設(shè)計(jì)如下，當(dāng)然有其他設(shè)計(jì)，比如用戶還款也可以通過合作方來進(jìn)行，但是系統(tǒng)的復(fù)雜度會(huì)高很多量級(jí)，故舍棄這個(gè)設(shè)計(jì)。
合作方：就是我們自己，對(duì)應(yīng)到這個(gè)題目就是阿里系的這個(gè)公司。

image.png

3 開發(fā)需求拆解

以上系統(tǒng)需求再拆解給開發(fā)，需求細(xì)節(jié)如下：

image.png

4 MLP

系統(tǒng)一般不會(huì)一開始就做很大，先做核心功能做測試和試錯(cuò)，所以我們現(xiàn)在定義一個(gè)最簡產(chǎn)品功能MLP，能打通渠道接入，引流給銀行完成放款后和合作方分傭的功能。

image.png

小結(jié)

以上，回看把最初一個(gè)抽象的方向性的需求變成一個(gè)落地的產(chǎn)品需求，就是一個(gè)產(chǎn)品經(jīng)理和技術(shù)TL撕逼到結(jié)果的過程。
有了可執(zhí)行的細(xì)節(jié)，后續(xù)才會(huì)有進(jìn)度排期，人力成本估算，產(chǎn)品發(fā)布計(jì)劃等。

整個(gè)系統(tǒng)架構(gòu)

整個(gè)系統(tǒng)架構(gòu)：
按照表現(xiàn)層 - 網(wǎng)關(guān)層 - 管理層 - 公共服務(wù) - 中間件/ 底層技術(shù)支持做了一個(gè)拆解

image.png

子系統(tǒng)架構(gòu)

• 貸款商品管理子系統(tǒng)
  銀行上架，消費(fèi)者可見
  銀行下架，消費(fèi)者不可見
  合作方，可以加一個(gè)上架商品審核，規(guī)避合規(guī)風(fēng)險(xiǎn)（非必需）。

  
  

• 渠道商戶管理
  渠道商戶分配appID，做訪問鑒權(quán)，調(diào)用統(tǒng)計(jì)
  訂單系統(tǒng)獲取商家信息通過該系統(tǒng)管理
  商家不合作之后通過該系統(tǒng)操作下線

  
  
  image.png

• 用戶管理
  用戶注冊，提交資料，認(rèn)證，查詢審批進(jìn)度等

  
  
  image.png

• 風(fēng)控報(bào)告
  作為合作方的核心賣點(diǎn)之一，通過用戶數(shù)據(jù)加工成可以對(duì)外輸出的報(bào)告
  注意：目前合規(guī)要求不允許直接買賣用戶數(shù)據(jù)，所以需要對(duì)于用戶數(shù)據(jù)加工成可對(duì)外輸出的數(shù)據(jù)，比如芝麻分這種，給到渠道。風(fēng)控報(bào)告是一種解決方式，銀行不再依賴原始數(shù)據(jù)來做風(fēng)控和貸審核，而是信任你這個(gè)合作方給出的信息評(píng)估。

  
  
  image.png

• 訂單管理
  整個(gè)系統(tǒng)流轉(zhuǎn)的核心部分就是一個(gè)訂單系統(tǒng)，用戶創(chuàng)建訂單，訂單到合作方加工，再到資金方去接單，然后放款（商品發(fā)貨），訂單的架構(gòu)可以參考電商產(chǎn)品，本文結(jié)合本系統(tǒng)做了簡化和修改

  
  
  image.png

技術(shù)選型

如果是阿里，其實(shí)不需要這個(gè)，因?yàn)榘⒗镉凶约旱囊惶组_發(fā)體系和框架，但是這個(gè)系統(tǒng)也可以被其他公司使用，所以大致列舉一下（后端 java 技術(shù)棧）。

• 表現(xiàn)層： Jquery，Ajax，Html，簡單常見容易招人
• 網(wǎng)關(guān)：SpringCloud Gateway，SpringCloud工具包還有注冊中心，配置中心可能也用得上，開源即用，比較適合創(chuàng)業(yè)公司，大公司一般自己開發(fā)網(wǎng)關(guān)。
• 管理層／公共基礎(chǔ)服務(wù)：管理層有很多服務(wù)，可以看出是一個(gè)微服務(wù)框架把大家組織起來的，springboot + springcloud，如果是阿里，大概率springcloud替換為dubbo，然后也需要一個(gè)前端，來配合做管理界面。
  風(fēng)控層面，如果有風(fēng)控引擎用風(fēng)控引擎，但是小公司沒有的話，基于規(guī)則做風(fēng)控也能滿足需求。
• 中間件/底層技術(shù)支持：mysql，規(guī)則引擎，打包發(fā)布，消息中間件等

技術(shù)團(tuán)隊(duì)構(gòu)成建議

image.png

寫在最后

到這里，整個(gè)系統(tǒng)結(jié)束了，說一下面試的后續(xù)，面試過程和一個(gè)優(yōu)秀的人發(fā)生了思想的碰撞，還是很讓人興奮，結(jié)果還沒給，但是對(duì)我而言，過程中帶來的結(jié)果，比過程目的更有趣，所以寫了這個(gè)分享，希望各位讀者老板喜歡。