1. 業(yè)務背景
按照慣例，先介紹一下業(yè)務背景。
公司有兩塊比較相似的業(yè)務領(lǐng)域，一個是統(tǒng)一登錄，一個是三方賬戶綁定。
統(tǒng)一登錄時公司自有業(yè)務渠道的登錄入口，主要完成帳戶登錄的鑒權(quán)，包括手機號+登錄密碼、用戶名+登錄密碼、短信驗證碼登錄等。和所有網(wǎng)站的登錄站點做的事情一樣，不再贅述。
三方賬戶綁定是指集團其他子公司之間通過身份認證+用戶授權(quán)綁定實現(xiàn)賬戶互信，賬戶首次綁定需要雙方做登錄鑒權(quán)操作，綁定之后只需要第三方賬戶登陸，用戶便可以免登陸的情況下獲得我司的登錄態(tài)權(quán)限。簡單業(yè)務流程如下：
注意：三方帳戶綁定服務端是在三方帳戶服務 thirdaccount 組件，登錄鑒權(quán)場景是在統(tǒng)一登錄服務 loginservice 組件。前端對應的靜態(tài)資源也是分開在兩個組件上。
2. 問題描述
可以看到‘三方帳戶綁定’的過程中，需要做我司帳戶登錄鑒權(quán)，這里的登錄鑒權(quán)和‘統(tǒng)一登錄’場景一樣，可以有多種登錄鑒權(quán)方式。這兩個業(yè)務場景對于前端來說，頁面都類似，流程也一樣。
前端同事遇到了疼點：兩個相似度極大的模塊靜態(tài)資源存在兩份，每次加入新的登錄鑒權(quán)方式，都需要兩邊維護，成本較高，因此，前端便希望抽象出統(tǒng)一的頁面和前端業(yè)務邏輯，配套的前端希望服務端統(tǒng)一提供一個登錄接口，這個接口既可以做純粹的登錄，也可以做‘三方帳戶綁定’，只需要多送兩個：三方業(yè)務渠道（channel）、三方帳戶標識（thirdAccountNo），服務端的接口判定thirdAccountNo是否有值來決定，在登錄鑒權(quán)完成后，是否需要做三方帳戶綁定。流程簡述如下：
但是服務端不贊成這樣做，服務端認為這樣會造成兩個獨立的業(yè)務領(lǐng)域耦合在一起，弊大于利。矛盾在此。
