В целом согласен с @Benjol. Здесь есть два разных типа отношений. Employee <-> EmployeeGroup - это отношение «домен», то есть отражает правила и характеристики проблемного пространства. Поэтому наиболее целесообразно моделировать как стандартную ассоциацию - многие: 1, если сотрудник может быть членом только одной группы, многие: многие в противном случае. Если честно, я бы не стал зацикливаться на агрегации. Мощность важнее.
Другие отношения скорее архитектурные, чем доменные. Я бы задокументировал это по отдельности - желательно со ссылкой на один или несколько архитектурных шаблонов. Взгляните на каталог Мартина Фаулера для хороших примеров.
Наконец, два замечания:
- Из вашего описания видно, что в проекте Employee & EmployeeGroup представлены как простые объекты значений со всей бизнес-логикой в EmployeeForm и EmployeeDBase. Я вообще с подозрением отношусь к перемещению доменной логики из доменных классов. Бывают случаи, когда это оправдано - обычно для действительно простых / быстрых хакерских систем. Все, что имеет какую-либо существенную доменную логику - и / или ожидается, что он будет иметь нетривиальный срок службы - обычно легче поддерживать, если логика домена лучше инкапсулирована с классами домена, а не связана с уровнями ui или db. (см. «Эрик Эванс« Проект, управляемый доменом »).
- «EmployeeGroup» - не самое информативное название. Из твоего описания лучше было бы назвать «EmployeeRole» или что-то подобное. Похоже, что это определено в книге, поэтому вы не можете что-то изменить.