Architecture 一个或两个UI，在业务功能上分开？

在我目前正在开发的一个应用程序中，作为主架构师，我们有两种截然不同的用户类型（比如员工和经理），99.9%的需求是不重叠的。目前，在一个新平台上构建我们的应用程序时，我突然面临一个危机：我使用的是一个UI层/应用程序，还是两个？我一直在思考宏观层面上适用的单一责任原则

我的应用程序在分层体系结构的基础上进行了很好的分解，因为我可以很容易地将一个新的UI放到事物上，因为所有业务关注点都正确地包含在一个单独的域层中，而不是UI中

这就是说，一旦用户通过了登录阶段，他们执行的功能几乎没有重叠。这两种类型的用户都在处理相同的数据——只是方式不同而已。例如，员工可能会“提交”某些内容，然后经理会“批准”或“拒绝”该内容。（一个做作但恰当的例子）

在我看来，我的选择是这样的：

一个庞大的UI，包含两种类型用户的所有UI功能，以及给定用户的可用功能，由现有角色/权限结构维护。
优点：在这种情况下，用户界面辅助功能、脚本、CSS等很容易得到普遍维护缺点：从组织结构来看，部署“员工”职能需要“经理”停工等更为困难

两个UI，本质上是一个EmployeeUI和一个ManagerUI，以及一个包含常用助手函数、静态脚本/CSS等的新库。优点：单独的功能意味着可以在不影响其他类型用户的情况下部署一类用户的关注点。对整体安全性的关注较少（即，每个UI的角色/权限数量较少），特定功能的维护更容易缺点：现在我有两个应用程序和一个库要维护。我确实有一些用户登录了这两个系统。（这是我们遗留应用程序中的现有方法）。我还必须确保这两个系统的部署计划相当相似，因为业务逻辑会随着时间的推移而变化

上周，有一天我100%相信他们应该分开。第二天，我有足够的怀疑犹豫

---

你对此有什么想法？你能提供一些例子吗？

在这里回答我自己的问题，不是出于自我，而是为了解释我最终选择的路线：

我选择了选项1。要维护的代码更少。用户的功能通过权限/角色进行了很好的分离，从长远来看，在这两个系统中工作的用户中，很少一部分人的多次登录将消失

是的，当需要更新时，我会在两个系统中都考虑停机时间，但计划的维护窗口通常会考虑到这一点，并且无论我选择哪种方法，我仍然必须计划它

我还更安全地知道，我的UI不会在不同的业务逻辑（版本）上运行，因为只有一个，而不是两个