Как Вы моделируете роли / отношения с Доменным Управляемым Дизайном в памяти?

Разве Вы не путающий "Описание" роли с ролью, которую человек имеет в проекте? Добавление понятия "RoleDescription" ('ролевой класс так сказать), и объекты "RoleInstance", относящиеся к фактическим людям в проектах, может помочь.

Вот то, как я обработал бы его:

class Person
{
  string Name { get; set; }
  IList<Role> Roles { get; private set; }
}

class Role
{
  string Name { get; set; }
  string Description { get; set; }
  IList<Person> Members { get; private set; }
}

class Project
{
  string Name { get; set; }
  string Description { get; set; }
  IList<ProjectMember> Members { get; private set; }
}

class ProjectMember
{
  Project Project { get; private set; }
  Person Person { get; set; }
  Role Role { get; set; }
}

Класс ProjectMember приносит им всем вместе. Эта модель дает Вам гибкость для присвоения того же Человека различным Проектам с различными Ролями (например, он мог бы быть Разработчиком на ProjectA и Тестером на ProjectB).

Не создавайте роль определенные классы - что урок уже был извлечен.

Я создал демонстрационное приложение для демонстрации этого (оно включает отношения также):

1. Выполненный "bin\debug\RolesRelationshipsSample.exe"
2. Дважды щелкните по значкам библиотеки для создания объектов
3. Перетащите/отбросьте их для присвоения соответствующих отношений

Не стесняйтесь играть с кодом. Надеюсь, что Вы находите это полезным.

То, что Вы имеете, является many-many отношениями с дополнительными данными, ролью. У нас есть подобная структура кроме нашего случая, у человека может быть несколько ролей на проекте, таким образом, я боролся с теми же вопросами. Одно решение состоит в том, чтобы создать класс ProjectPerson, который расширяет Человека и добавляет ролевое свойство:

public class ProjectPerson : Person
{
    public string Role { get; set; }
}

Ваш класс Проекта теперь имеет набор ProjectPerson, но класс Человека имеет набор Проекта, потому что не имеет смысла расширять класс Проекта для добавления роли. Необходимо будет сделать некоторую дополнительную работу (ищите Человека в наборе ProjectPerson) найти роль на Проекте с точки зрения Человека.

Вторым решением является стандартный способ обработать many-many отношения с дополнительными данными. Создайте класс ProjectRole и смоделируйте его, поскольку многие примыкают двух связей "один ко многим" из Проекта и Человека. Таким образом, и Проект и Человек у каждого есть набор ProjectRole.

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

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

Примечание. В таблицы поиска могут быть добавлены записи, но обычно значение записи не изменяется. После того, как значение выбрано из справочной таблицы, оно считается постоянным элементом таблицы-владельца - в данном случае таблицы Project Member.

Я бы не ожидал увидеть сущность или таблицу «Человек» в каком-либо бизнесе, кроме удобства в виде таблицы поиска, как в приведенном выше случае. HR-отделы будут вести список сотрудников, у которых есть конкретная информация, которая требуется для расчета заработной платы и т. Д., Но нет ничего фундаментального в отношении людей, которые необходимо знать бизнесу. NB Найдите бизнес-процесс, чтобы идентифицировать сущность - не придумывайте.