業務背景
按照慣例，先介紹一下業務背景。
公司有兩塊比較相似的業務領域，一個是統一登錄，一個是三方賬戶綁定。
統一登錄時公司自有業務渠道的登錄入口，主要完成帳戶登錄的鑒權，包括手機號+登錄密碼、用戶名+登錄密碼、短信驗證碼登錄等。和所有網站的登錄站點做的事情一樣，不再贅述。
三方賬戶綁定是指集團其他子公司之間通過身份認證+用戶授權綁定實現賬戶互信，賬戶首次綁定需要雙方做登錄鑒權操作，綁定之后只需要第三方賬戶登陸，用戶便可以免登陸的情況下獲得我司的登錄態權限。簡單業務流程如下：
注意：三方帳戶綁定服務端是在三方帳戶服務 thirdaccount 組件，登錄鑒權場景是在統一登錄服務 loginservice 組件。前端對應的靜態資源也是分開在兩個組件上。
問題描述
可以看到‘三方帳戶綁定’的過程中，需要做我司帳戶登錄鑒權，這里的登錄鑒權和‘統一登錄’場景一樣，可以有多種登錄鑒權方式。這兩個業務場景對於前端來說，頁面都類似，流程也一樣。
前端同事遇到了疼點：兩個相似度極大的模塊靜態資源存在兩份，每次加入新的登錄鑒權方式，都需要兩邊維護，成本較高，因此，前端便希望抽象出統一的頁面和前端業務邏輯，配套的前端希望服務端統一提供一個登錄接口，這個接口既可以做純粹的登錄，也可以做‘三方帳戶綁定’，只需要多送兩個：三方業務渠道（channel）、三方帳戶標識（thirdAccountNo），服務端的接口判定thirdAccountNo是否有值來決定，在登錄鑒權完成后，是否需要做三方帳戶綁定。流程簡述如下：
但是服務端不贊成這樣做，服務端認為這樣會造成兩個獨立的業務領域耦合在一起，弊大於利。矛盾在此。
各抒己見
客戶端的觀點
1、‘三方帳戶綁定’和‘登錄鑒權’場景的目標都是為了生成我司帳戶登錄態，里面的大部分業務邏輯是公共的，除去‘帳戶綁定’這一步。因此，可以統一納入到統一登錄服務這個入口完成。
2、從開發和維護成本來講，后續增加新的登錄鑒權方式，只需要更改一套代碼就ok了，不需要既更改 thirdaccount 和 loginservice。
服務端的觀點
1、從純粹的業務領域來講，登錄和三方帳戶綁定是兩個不同的業務領域，不應當將‘三方帳戶綁定’納入到‘登錄鑒權’的業務領域。雖然他們最終都得到共同結果——生成我司帳戶登錄態。
2、從業務安全角度上來講，不同安全級別的業務應當做隔離。三方帳戶綁定這種‘授信’式的鑒權方式安全性相對並不高，很大程度上依賴於合作伙伴的安全性，而登錄鑒權作為我司自有的登錄入口，我們可以做很多安全加固：圖片驗證碼、帳戶鎖定邏輯、風控接入等，不同安全級別的業務做隔離的好處在於，出現緊急事件時，我們可以將風險隔離在較小的范圍內，這樣緊急處理起來牽掛更少。
3、從業務核心維度來看，‘登錄並綁定’中的‘帳戶綁定’才是我們的核心業務，‘登錄鑒權’只是這個核心業務目標中的一個環節，所以‘三方帳戶綁定’場景就應當放在 thirdaccount 組件里。
4、從組件依賴上來看，關鍵路徑服務組件 loginservice 不應當反向依賴於非關鍵路徑服務組件 thirdaccount。在反向依賴的情況下，一旦 thirdaccount 組件出現故障，很可能拖累道 loginservice，進而影響到自有渠道的帳戶登錄。
5、從開發成本角度來看，thirdaccount並不會增加太多的開發和維護工作。在 thirdaccount 提供的‘登錄並綁定’ 服務契約兼容‘登錄鑒權’服務契約的前提下，thirdaccount只需要在需要鑒權的時候透傳請求給loginservice即可，而且如果契約設計良好，及時增加新的登錄鑒權方式，也不需要更改thirdaccount。
達成一致
服務端的3、4點理由存在相當的合理性，最終前后端達成一致，服務端不應當將 ‘三方帳戶綁定’ 服務合並至 ‘登錄鑒權’ 服務，為了配合前端的頁面抽象，服務端在 thirdaccount 提供一個新的通用 ‘登錄並綁定’ 服務給前端，該服務和現有的 ‘登錄鑒權’ 服務契約兼容，前端自行根據是否存在 ‘三方帳戶標識（thirdAccountNo）’ 來決定是調用 loginservice 的登錄服務，還是調用thirdaccount的 ‘登錄並綁定’ 服務， 簡要流程和圖一保持不變。
心得
1、分清討論case的核心點，不要被細枝末節干擾。搞清楚業務case的業務目標是什么？這個目標就是你的業務核心點，就像 ‘登錄並綁定’ case，既有 ‘登錄’ 又有 ‘綁定’，但是 ‘綁定’ 才是核心點，‘登錄’ 是為了 ‘綁定’ 而做的，‘綁定’ 才是我們的業務目標；
2、關鍵路徑服務盡量少依賴其他服務，尤其是非關鍵路徑服務。例如本例中的 loginservice 不應當依賴於 thirdaccount；
3、不要為了眼前的便利做過度的抽象，后續可能的業務變化會讓過度抽象成為鐐銬。比如如果這次將 ‘三方帳戶綁定’ 並入到 ‘登錄鑒權’ 服務中，現在看來一個服務搞定了，但是假如后續有一個三方渠道不在 thirdaccount 服務組件中處理，那么loginservice就需要再次依賴其他業務組件，需要更改抽象出來的公共服務，最后適得其反。