一個理財平臺可以從不同的維度來看。對于一個消費者來說，最宏觀的看法，P2P公司的理財平臺相當于一個中介，一邊用于對接用戶，一邊用于對接產品提供商。這個中介系統負責用戶和產品提供者之間的交互。對于一個P2P理財公司來說，最核心的兩個模塊是財務賬目模塊和運行模塊。其他的模塊都是基于這兩個核心來擴展的。

1. 把登陸模塊單獨拎出來，是為了日后進行登陸安全控制；追蹤客戶記錄進行大數據分析；
2. 概念：結算和清算，清算是兩個系統之間，如P2P公司和銀行之間，是發生在兩個獨立系統結算之外的。結算則是本系統內的一種賬務計算，它只限于本系統。

什么是好的架構系統？看上面的業務架構圖，它嚴格的定義了各個模塊的邊界。對于一個需求，我們寫在哪個系統的哪個部分，都唯一確定，而不會產生模棱兩可的狀況。碼農所做的工作就是在相應的格子中填充代碼，完成相應的單元測試。架構的設計要解耦，比如一個客戶購買P2P公司的一款理財產品，他在H5端下單付錢，P2P公司的理財平臺要對接到銀行，從客戶的銀行卡扣錢，銀行扣錢成功要通知P2P平臺，這個通知很大概率是收不到的。這就涉及到了消息傳遞的同步和異步。我們先舉個例子，A在微信上向B發了一條微信消息，A立即接受到了發送成功，但是此時消息只是到達了A服務器，(假如A服務器有足夠策略保證把接受到的消息發送到B服務器，再遞推到B客戶)。這就是簡單的同步和異步問題。如果你問我同步好？還是異步好，一般公司的是先采用同步方式，后采用異步方式，因為異步方式需要單獨的開發消息傳送機制。而且是當數據體量特別大的時候，才去采用異步方式來提高效率。

OP平臺的全稱是Operation Platform，看上面的圖：

1. 圖的最左側，運營平臺面向的對象是：產品人員(錄標)、結算人員、客服人員和管理人員(測試人員，開發人員等)。
2. 運營平臺依賴于財務系統、會員系統、交易系統、合同系統。客戶和平臺之間的每次交易都一份合同，當然是電子合同。
3. OP系統要做的工作是途中所標注的那些模塊，這是技術研發人員向管理者和運營人員、市場人員、測試人員開放的接口。

如上圖所示，是P2P理財平臺的表結構的設計：

1.  大致分為七大類，當然隨著項目的運維后續還會陸續的有擴表(尤其適合后臺管理部分的表結構)，粗看表結構的命名規則包括有：T_、P_、OP_、相應的分別表示Trade(交易平臺)、PRoduce(產品平臺)、Operation Platform(運營平臺)。
2. 在變量的字段定義中，主要使用的類型只有：varchar(128)、char(1)、date、number(15)這四種，稍微提及一下，char的長度是固定的、varchar的長度是可變化的；char的效率比varchar效率高<這也是標記狀態的字段一般均使用char(1)來定義數據類型>，因為char初始化時已經在硬盤上申請好了空間，而varchar在使用時才分配空間，所以使用時要先分配空間，故而效率低;date是日期類型，具體顯示成什么樣子那是顯示問題，它的本質上還是一個日期類型。number類型是存數字的，varchar和char畢竟存的是字符串；當然了number(5)表示存5位整數，number(5,2)表示存5位數，其中2位小數。<如果表的主鍵用NUMBER類型，在用“SELECT * FROM TEST WHERE ID = xxx”這種類型的SQL語句時比之VARCHAR類型的要快？因為VARCHAR類型如果較長的話，數據庫將會逐個逐個字符比較，這樣，它找出該條記錄的速度比較慢。>
3. 重點看一下會員表，因為任何一個系統：電商平臺、互聯網金融、在線教育、O2O都需要保存用戶的登陸記錄。T_Login_Token表，token的原則是注冊或首次登陸成功后下發，每次登陸成功后修改，同時這個表中還記錄了登陸的設別手機型號，序列號等詳細設備信息。T_Login_History對登陸歷史做了記錄，以后可以用于用戶行為監控，以及萬一出現金融事故之后，可以查找線索。另外還有對接第三方的短信驗證表、銀行卡表、身份證驗證表。

上圖的表示詳細的表結構，應該蠻詳細的，尤其是對設備號的跟蹤，登陸token的記錄等。

接下來，再來回顧一下系統依賴圖， 對于用戶來說，他們的視角是ios、android、pc、h5四個入口，這四個入口用于對外展現公司的產品目錄，大部分情況下他們的交互是與后臺通過接口來交互，也有少部分情況需要不同的設備之間進行交互。對于后臺的交互，Controller對于相應的請求request，做出相應的業務邏輯處理后，封裝到response返回給四個終端。

上圖所示，定義的接口規范是用于終端和后臺進行的數據交互，最常用的可以使用jQuery封裝好的Ajax來獲取請求。下面是一個Android客戶端需要調用H5的時候定義的一些公共接口文檔。