ビジネス機能で分離された1つまたは2つのUI？

Question

私が現在取り組んでおり、主要アーキテクトとして働いているアプリケーションでは、かなり重複しないタイプのユーザーが2人（従業員とマネージャー）あり、99.9％は重複しません。現時点では、新しいプラットフォームでアプリケーションを構築するにあたり、私は突然危機に直面しています.1つのUIレイヤー/アプリケーション、または2つを使用しますか？私は、マクロレベルで適用される単一責任原則について考え続けています。

私のアプリケーションは階層化されたアーキテクチャに基づいてかなりうまく分割されています。すべてのビジネス上の懸念事項が別々のドメインレイヤーに適切に含まれているためUI。

つまり、ユーザーがログイン段階を過ぎると、実行する機能にはほとんど重複がありません。どちらのタイプのユーザーも同じデータに対してさまざまな方法で行動しています。一例として、従業員は何かを「提出する」ことができ、マネージャはそれを「承認」または「拒否」します。 （考案されたが適切な例）。

私はそれを参照してください方法は、私の選択は、次のように推論されています。特定のユーザーにすべてのユーザーの両方のタイプのUI機能、および利用可能な機能を含む

1. 一つの巨大なUIは、既存によって維持されています役割/権限構造。
   PRO：この場合、UIヘルパ関数、スクリプト、CSSなどを共通に維持するのは簡単です。 短所：それは組織構造から、より困難だ、「従業員」の機能の展開等、「マネージャー」のダウンタイム、

2. つの一般的なヘルパーが含まれている新しいライブラリと一緒のUI、本質的EmployeeUIとManagerUIを、必要静的なスクリプト/ CSSなどPRO：別個の機能とは、1つのタイプのユーザーに対する懸念が、他のタイプに影響を与えずに展開できることを意味します。全体的なセキュリティ（UIあたりのロール/パーミッションの数がより少ない）が懸念されることは少なく、特定の機能のメンテナンスが容易です。 CONs：今、私は2つのアプリケーションと、保守するライブラリを持っています。そして、私は両方のシステムへのログインを持っている一握りのユーザーを持っています。 （これは従来のアプリの既存のアプローチです）。また、ビジネスロジックが時間の経過と共に変化するため、両方のシステムが合理的に同様の配備スケジュールになっていることを確認する必要があります。

先週、私は彼らが分別されるべきだと確信しました。次に、私は躊躇する十分な疑いがあった。

どのような考えがありますか？いくつかの例を挙げることができますか？

Answer 1

ない自我の外に、ここで自分の質問に答えるが、ちょうど私が撮影を巻き取るルートの説明を提供する：

私は維持するためのオプション1.少ないコードを選択しました。ユーザーの機能はパーミッション/役割によってうまく分離されていますが、そこから出てきた小さな利点は、長期的には両方のシステムで働くユーザーの割合が非常に低いため複数のログインがなくなることです。

はい、どちらのシステムでもダウンタイムが発生しますが、アップデートが必要になるとスケジュールされたメンテナンスウィンドウが一般的に処理されます。どのアプローチを選択したとしても、 。

私は、UIが異なるビジネスロジック（バージョン）で動作しないことを知っている方が安全です。単純に2つではなく2つではないからです。