Иерархия специализаций в доменной модели

Question

Я пытаюсь сделать предметную модель системы управления. У меня есть следующие люди в этой системе:

employee
manager
top mananger

Я решил определить User, откуда Employee, Manager и Top Manager будут специализироваться. Я не знаю, какую иерархию специализаций мне выбрать. Я не могу выбрать один из следующих способов:

или

Что может быть предпочтительнее и почему?

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

Спасибо

EDIT:

Скажу немного точнее: это программа для управления планами отпусков работников. С помощью этой программы сотрудник может выбрать набор выходных дней в году. Тогда менеджер может утвердить или нет те дни для каждого из сотрудников, и в конце дня топ-менеджер должен одобрить или не одобрить решения менеджера. Это все, что должны делать пользователи моей программы. Других заданий нет.

Answer 1

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

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

С другой стороны, в некоторых местах, где существует множество правил профсоюзов, это может быть совсем не так. Даже если человек полностью способен выполнять работу, правила могут не позволять ему вообще занимать эту должность. В некоторых случаях это вытекает из требований сертификации и тому подобного (например, менеджер может иметь квалификацию, необходимую для выполнения работы, но требуемая сертификация утратила силу) или из таких вещей, как правила профсоюза (например, мой друг, который однажды получил выговор из-за он принес лампочку с фонариком и батарею из фирменного магазина обратно в свою лабораторию вместо того, чтобы сделать это для него со стороны работника профсоюзных материалов).

Answer 2

В реальной жизни Менеджеры тоже являются Сотрудниками. Так что это, безусловно, просто цепь растущей специализации:

User -> Employee -> Manager -> Top Manager 

редактировать

"Это программа для управления планы отпусков рабочих. "

В вашей компании Менеджеры берут запланированный отпуск? Конечно, они делают. И точно так же вы не собираетесь создавать отдельное приложение для управления этим. Так что вам действительно нужно это:

User -> Requester
     -> Approver

Каждый Пользователь будет Запрашивающим в одной цепочке утверждений. (Вам могут потребоваться специальные меры для генерального директора). Кроме того, некоторые пользователи будут утверждающими в одной или нескольких цепях. Окончательный утверждающий, вероятно, будет различаться в зависимости от класса заявителя: генеральный директор не захочет беспокоиться об утверждении порядка отпусков обслуживающего персонала.

Вам понадобятся некоторые правила для обеспечения того, кто может быть утверждающим на праздники любого заявителя. Если у вас нет чрезвычайно плоской организации, вы обнаружите, что у вас есть иерархия рабочих и менеджеров. Например, руководитель группы или бригадир - люди, которые в других отношениях являются «работниками», а не «менеджерами» - могут быть в цепи. Также вам может понадобиться рассмотреть другие аспекты организации. Например, если работник желает перенести отпуск на следующий год, который может потребовать одобрения отдела кадров, кто-то, кто обычно не несет никакой управленческой ответственности за сотрудника.

Редактировать 2

Хорошо, мы моделируем произвольный набор правил, а не реалистичный сценарий.

Посмотрим. Каждый пользователь вписывается в одну категорию, определяемую этими задачами:

• Сотрудник может запросить отпуск
• менеджер может утвердить или отклонить запрос на отпуск
• Топ-менеджер может принять или отменить утверждение или отклонение

Менеджеры и топ-менеджеры не имеют общего поведения. Следовательно, первая модель является правильной.

Answer 3

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

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

Разница в моделировании пользователя / менеджера / сотрудника как актеров и ролей заключается в том, что вы можете сосредоточиться на моделировании того, что вам нужно поместить в систему, поскольку вам не нужно иметь иерархию актеров - вы начинаете использовать абстракцию при использовании кейс и системный уровень сущности, а не в субъектах. Не всегда плохая идея подумать «как это будет работать в коде», по крайней мере настолько, чтобы спросить «зачем беспокоиться о кодировании этого различия».