Один или два интерфейса, разделенные на бизнес-функции?

Question

В приложении, над которым я сейчас работаю и выступаю в качестве основного архитектора, у нас есть два довольно разных типа пользователей (скажем, сотрудники и менеджеры) с 99,9% непересекающихся потребностей.В настоящее время, создавая наше приложение на новой платформе, я внезапно столкнулся с кризисом: использую ли я один уровень / приложение UI или два?Я продолжаю думать о Едином принципе ответственности, применяемом на макроуровне.

Мое приложение разбито довольно хорошо по многоуровневой архитектуре, так как я могу довольно легко создать новый пользовательский интерфейс для вещей довольно легко, поскольку все проблемы бизнеса должным образом содержатся в отдельном доменном слое, а не в пользовательском интерфейсе.

При этом после того, как пользователь прошел этап входа в систему, функции, которые они выполняют, перекрываются очень мало.Оба типа пользователей работают с одними и теми же данными - просто по-разному.Например, сотрудник может «представить» что-то, а менеджер затем «одобряет» или «отклоняет» это.(надуманный, но удачный пример).

На мой взгляд, мой выбор обоснован следующим образом:

1. Один массивный пользовательский интерфейс, содержащий все функции пользовательского интерфейса для обоих типовпользователей и доступные функции для данного пользователя поддерживаются существующей структурой ролей / разрешений.
   PRO: В этом случае легко использовать вспомогательные функции пользовательского интерфейса, сценарии, CSS и т. д.обычно поддерживается. CON: Это сложнее из организационной структуры, развертывание функций "сотрудника" требует простоев "менеджера" и т. Д.

2. Два интерфейса пользователя, по сути EmployeeUI иManagerUI вместе с новой библиотекой, которая содержит общие вспомогательные функции, статический скрипт / CSS и т. Д. PRO: Отдельная функциональность означает, что проблемы для одного типа пользователей могут быть развернуты без влияния на другой.Меньше заботятся об общей безопасности (то есть о меньшем количестве ролей / разрешений на пользовательский интерфейс), а обслуживание определенных функций проще. CONs: Теперь у меня есть два приложения и библиотека для обслуживания.И у меня есть несколько пользователей, которые имеют логины для обеих систем.(Это существующий подход в наших старых приложениях).Я также должен убедиться, что обе системы находятся в достаточно схожем графике развертывания, поскольку бизнес-логика со временем меняется.

На прошлой неделе, однажды я был на 100% убежден, что они должны бытьразделены.Затем у меня было достаточно сомнений, чтобы колебаться.

Какие у вас есть мысли по этому поводу?Можете привести несколько примеров?

Answer 1

Отвечая на мой собственный вопрос здесь, не из-за эго, но просто для того, чтобы дать объяснение пути, по которому я в итоге пошел:

Я выбрал вариант 1. Меньше кода для обслуживания.Функции пользователей хорошо разделены по разрешениям / ролям, и из этого получилось небольшое приятное преимущество, заключающееся в том, что в конечном итоге множественные входы в систему исчезнут для очень небольшого процента пользователей, работающих в обеих системах.

Да, я возьму время простоя в обеих системах, когда придет время для обновлений, но окно планового обслуживания обычно учитывает это, и независимо от того, какой подход я выбрал, мне все равно пришлось бы планировать его..

Мне также безопаснее знать, что мои пользовательские интерфейсы не будут работать с другой бизнес-логикой (версиями), поскольку будет просто один, а не два.