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