一個或兩個用戶界面分開業務功能？

Question

在我目前正在開發的應用程序中，作爲主要架構師，我們有兩種截然不同類型的用戶（稱爲員工和經理），擁有99.9％的非重疊需求。目前，在一個新的平臺上構建我們的應用程序時，我突然面臨危機：我是否使用一個UI層/應用程序，或兩個？我一直在思考在宏觀層面上應用的單一責任原則。

我的應用程序在分層架構的基礎上被很好地分解了，因爲我可以很容易地在事物上添加一個新的UI，因爲所有業務關注點都被恰當地包含在一個單獨的域圖層中，而不是UI。

也就是說，一旦用戶通過登錄階段，他們執行的功能就幾乎沒有重疊。兩種類型的用戶都採用相同的數據 - 只是採用不同的方式。例如，員工可以「提交」某些內容，然後經理「批准」或「拒絕」該內容。 （一個人爲的例子）。

我看到它的方式，我的選擇是理由是這樣的：

1. 一個龐大的用戶界面，包含兩種類型的用戶給定用戶的所有UI功能，並可用功能由現有的維護角色/權限結構。
   PRO：在這種情況下，UI助手功能，腳本，CSS等通常很容易維護。 缺點：它更難以從組織結構，「僱員」功能部署必要對「經理人」停機等

2. 兩個用戶界面，基本上是一個EmployeeUI和ManagerUI，以及包含常見的幫手一個新的圖書館功能，靜態腳本/ CSS等。PROs：單獨的功能意味着可以在不影響其他用戶的情況下部署一種類型的用戶。對整體安全性的關注較少（即每個用戶界面的角色/權限數量較少），並且維護特定功能更加容易。 CONs：現在我有兩個應用程序加上一個庫來維護。而且我確實有少數用戶登錄到這兩個系統。 （這是我們傳統應用程序中的現有方法）。我還必須確保兩個系統的配置時間表相當相似，因爲業務邏輯會隨着時間而改變。

上週，有一天我100％確信他們應該分開。接下來，我有足夠的懷疑猶豫。

你有什麼想法？你能提供一些例子嗎？

Answer 1

回答我的問題在這裏，沒有了自我，而只是提供路線的解釋，我清盤了結：

我選擇了選項1.維護更少的代碼。用戶的功能通過權限/角色進行了很好的分離，並且從中獲得的好處是，從長遠來看，對於在兩個系統中工作的用戶來說，多個登錄將會消失。

是的，當需要更新時，我會在兩個系統中採用停機時間，但計劃的維護時段通常會處理此問題，無論我選擇哪種方法，我仍然必須安排它。

我也更安全地知道我的用戶界面不會在不同的業務邏輯（版本）上運作，因爲只有一個而不是兩個。