Я повреждаю свои совокупные границы в этой модели?

Я моделирую очень простой ASP.NET приложение MVC с помощью NHibernate, и я, кажется, застреваю на своем дизайне. Вот эскиз моей модели:

model 1

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

var user = userRepository.Load(1);
var list = user.Organizations; // All the organizations the user is a part of.

и

var org = orgRepository.Load(1);
var list = org.Users; // All the users in an organization.

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

8
задан Glorfindel 20 July 2019 в 11:04
поделиться

6 ответов

Я несколько раз использовал подход, аналогичный вашей первой модели. Единственная загвоздка этого подхода заключается в том, что вам необходимо создать класс OganizationUser в вашем домене для обработки полей Role и Flagged из вашего домена. В результате в вашем коде останется что-то подобное.

var user = userRepository.Load(1);
var list = user.OrganizationUsers; // All the organizations the user is a part of including their role and flagged values.

var organization = list[0].Organization; 

* Если вы собираетесь довольно часто перебирать все организации пользователей, вы, вероятно, захотите загрузить сущность Organization вместе с OrganzitionUser

Похоже, что со вторым отправленным вами дизайном вы сможете добавить пользователя в OrgUserDetails , не добавляя пользователя в OrganizationUser . Это не

2
ответ дан 5 December 2019 в 15:25
поделиться

Это типичная связь "многие-ко-многим". А таблицы Organization_Users - это таблица моста. Infact NHibernate и все другие инструменты ORM имеют встроенную функцию для поддержки таблицы мостов.

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

Первое. Во-первых, вам нужно убедиться, что отношение «многие ко многим» в модели данных необходимо для сопоставления сущностей предметной области. Как только вы это сделаете, модель, представленная на вашей диаграмме, подходит для отображения этих отношений на уровне приложения

4
ответ дан 5 December 2019 в 15:25
поделиться

Первое, что следует учитывать в DDD:

  • забудьте схему базы данных (там нет базы данных!)
  • какие действия вы будете выполнять с этими объектами с точки зрения домена?
2
ответ дан 5 December 2019 в 15:25
поделиться

Думаю, ваша модель в порядке. Я обычно думаю о совокупных корнях предметной области, когда я вообще думаю о них, с точки зрения того, что открыто, а не внутренней реализации. Что касается отношений, я думаю о том, какая сущность «носит штаны» в отношениях. То есть, что более естественно: добавить пользователя в организацию или добавить организацию в пользователя? В этом случае оба варианта могут иметь смысл: Пользователь присоединяется к Организации; Организация принимает пользователя для членства.

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

В ответ на ваш второй проект (было бы лучше, если бы вы отредактировали исходный вопрос): Мне он совсем не нравится. Ваш оригинальный дизайн в порядке. Я бы не обязательно игнорировал базу данных при разработке ваших классов, хороший дизайн должен точно моделировать домен и быть простым для реализации в реляционной базе данных. Иногда вам приходится идти на компромисс в обоих направлениях, чтобы попасть в золотую середину. Нет тюремного заключения за нарушение совокупных границ. : -)

2
ответ дан 5 December 2019 в 15:25
поделиться

Насколько я понимаю:

Пользователь может принадлежат к организациям "0 ко многим". И Организация состоит из пользователей типа "0 ко многим".

Верны ли оба утверждения? Если так, то для меня это звучит как «многие-ко-многим».

В случае «многие-ко-многим» вам в значительной степени нужен объект, подобный отношениям, чтобы преодолеть этот разрыв. Проблема в том, что в домене нет user_organization.

Это заставляет меня думать, что вы не должны иметь user_organization как часть вашего домена как таковую. Это похоже на деталь реализации.

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

1
ответ дан 5 December 2019 в 15:25
поделиться

Спасибо всем за ответы. Они мне очень помогли.

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

alt text

Я думал так:

  1. Когда пользователь входит на сайт, система находит его учетную запись и затем возвращает список организаций, от которых они не входят, и получает эту информацию от объекта user_organizations.

  2. Когда пользователь нажимает на одну из организаций, от которых они не входят, он направляет его на панель управления организации.

  3. Выбранные Затем организация ищет роль этого пользователя в своем org_user_details, чтобы узнать, какой доступ пользователь должен иметь к панели управления этой организации.

Имеет ли это смысл? :)

Я чувствую, что это было бы хорошо для модели, но у меня есть некоторые сомнения по поводу реализации БД. Я знаю, что мне даже не стоит об этом беспокоиться, но я пока не могу избавиться от своей вредной привычки! Вы можете видеть, что в объекте user_organizations и org_user_details есть как бы повторяющиеся данные. Я не профессионал в БД, но разве это плохой дизайн БД? Должен ли я вместо этого объединить данные из user_organizations и org_user_details в таблицу, подобную той, что была в моем первом сообщении, и просто сказать NHibernate, что пользователь смотрит на нее как на связь "многие ко многим", а организация рассматривает ее как связь "один ко многим". ? Похоже, я обманываю систему. Извините, если я действительно запутался в этом.

Что вы думаете по этому поводу? Я слишком много думаю об этом? : P

Вы можете видеть, что в объекте user_organizations и org_user_details есть как бы повторяющиеся данные. Я не профессионал в БД, но разве это плохой дизайн БД? Должен ли я вместо этого объединить данные из user_organizations и org_user_details в таблицу, подобную той, что была в моем первом сообщении, и просто сказать NHibernate, что пользователь смотрит на нее как на связь "многие ко многим", а организация рассматривает ее как связь "один ко многим". ? Похоже, я обманываю систему. Извините, если я действительно запутался в этом.

Что вы думаете по этому поводу? Я слишком много думаю об этом? : P

Вы можете видеть, что в объекте user_organizations и org_user_details есть как бы повторяющиеся данные. Я не профессионал в БД, но разве это плохой дизайн БД? Должен ли я вместо этого объединить данные из user_organizations и org_user_details в таблицу, подобную той, что была в моем первом сообщении, и просто сказать NHibernate, что пользователь смотрит на нее как на связь "многие ко многим", а организация рассматривает ее как связь "один ко многим". ? Похоже, я обманываю систему. Извините, если я действительно запутался в этом.

Что вы думаете по этому поводу? Я слишком много думаю об этом? : P

m не профессионал в БД, но разве это плохой дизайн БД? Должен ли я вместо этого объединить данные из user_organizations и org_user_details в таблицу, подобную той, что была в моем первом сообщении, и просто сказать NHibernate, что пользователь смотрит на нее как на связь "многие ко многим", а организация рассматривает ее как связь "один ко многим". ? Похоже, я обманываю систему. Извините, если я действительно запутался в этом.

Что вы думаете по этому поводу? Я слишком много думаю об этом? : P

m не профессионал в БД, но разве это плохой дизайн БД? Должен ли я вместо этого объединить данные из user_organizations и org_user_details в таблицу, подобную той, что была в моем первом сообщении, и просто сказать NHibernate, что пользователь смотрит на нее как на связь "многие ко многим", а организация рассматривает ее как связь "один ко многим". ? Похоже, я обманываю систему. Извините, если я действительно запутался в этом.

Что вы думаете по этому поводу? Я слишком много думаю об этом? : P

0
ответ дан 5 December 2019 в 15:25
поделиться
Другие вопросы по тегам:

Похожие вопросы: