在我目前正在开发的一个应用程序中，作为主要架构师，我们有两个非常不同类型的用户（比如员工和经理），99.9％的非重叠需求。目前，在新平台上构建我们的应用程序时，我突然面临一个危机：我是使用一个UI层/应用程序，还是两个？我一直在思考在宏观层面应用的单一责任原则。
我的应用程序在分层架构的基础上很好地分解，因为我可以很容易地在事物上放置新的UI，因为所有业务问题都适当地包含在单独的域层中，而不是在UI。
也就是说，一旦用户超过登录阶段，他们执行的功能几乎没有重叠。两种类型的用户都以不同的方式处理相同的数据。例如，员工可以“提交”某些内容，然后管理员“批准”或“拒绝”它。 （一个人为但又恰当的例子）。
我看待它的方式，我的选择是这样推理的：
现有的角色/权限结构维护了一个包含两种类型用户的所有UI功能以及给定用户的可用功能的大型UI。 PROs：在这种情况下，通常可以轻松维护UI辅助函数，脚本，CSS等。 CONs：从组织结构来看，“雇员”功能的部署需要“经理”停机等等，这样做更加困难。
两个UI，基本上是一个EmployeeUI和一个ManagerUI，以及一个包含常见辅助函数，静态脚本/ CSS等的新库。 PROs：单独的功能意味着对一个人的关注可以部署用户类型而不影响另一个用户。对整体安全性的关注较少（即，每个UI的角色/权限数量较少），并且特定功能的维护更容易。 CONs：现在我有两个应用程序和一个要维护的库。我确实有一些用户可以登录这两个系统。 （这是我们遗留应用程序中的现有方法）。我还必须确保两个系统都处于相当类似的部署计划中，因为业务逻辑会随着时间的推移而发生变化。
上周，有一天我100％确信他们应该分开。接下来，我有足够的怀疑犹豫。
你有什么想法？你能提供一些例子吗？
答案 0 :(得分：1)
在这里回答我自己的问题，不仅仅是出于自我，而只是为了解释我最后选择的路线：
我选择了选项1.维护的代码更少。用户的功能通过权限/角色很好地隔离，并且从中获得的一个很好的好处是，从长远来看，多个登录将消失在两个系统中工作的极小百分比的用户。
是的，当需要更新时，我会在两个系统中停机，但是计划维护窗口通常会处理这个问题，无论我选择哪种方法，我仍然需要安排它。
我也更安全地知道我的UI不会在不同的业务逻辑（版本）上运行，因为只有一个而不是两个。