Проблема корневых агрегатов в доменном дизайне - PullRequest
0 голосов
/ 10 декабря 2010

У меня есть два Entity Publisher и SocialAccount, оба являются независимыми и имеют отношение Многие ко Многим. Оба являются корневыми агрегатами, теперь я не могу получить социальную учетную запись через Publisher, и я хочу преобразовать отношение М в М в 1 в М. Поэтому я ввел регистрацию другого объекта, будет иметь {PubID, SocID, CreateDate}. Теперь между издателем и регистрацией существует отношение 1 к М, а между регистрацией и SocialAccount - 1 к 1. поэтому у издателя будет

Список _Registrations {get; set;}

Но когда я создаю границы агрегатов, Publisher является моим корнем, и в соответствии с принципом агрегации только корневой агрегат будет содержать ссылку на другой корневой агрегат. Но здесь Регистрация держат ссылку.

Так же я нарушаю агрегатный принцип, потому что регистрация связана с учетной записью Social Account.

Ответы [ 2 ]

4 голосов
/ 10 декабря 2010

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

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

Добавив регистрацию, вы говорите, что не можете содержать ссылку на социальную учетную запись, поскольку она является частью Publisher.Это не правило, но более важно, как Регистрация внезапно стала частью агрегата Издателя?В силу только того, что Publisher имеет коллекцию Registration?

Агрегат - это группа объектов, которые рассматриваются как одна единица для поддержки состояния и инвариантов.Существование отношений само по себе не дает членства в совокупности.

Но посмотрите на другую сторону сейчас.Регистрация 1 к 1 с социальной учетной записью.И если мы удаляем Социальную учетную запись, имеет ли смысл когда-либо регистрироваться у издателя?Если нет, то регистрация, вероятно, фактически является частью совокупности SocialAccount.Вот почему мы создаем агрегаты - чтобы гарантировать, что объекты и их отношения всегда действительны после изменения состояния.Если изменение состояния удаления SocialAccount включает в себя удаление всех регистраций, связанных с этой учетной записью, мы бы хотели включить его в совокупность, чтобы применить это правило.

Теперь вы действительно нарушили «правило агрегирования» - у вас есть внешняя связь между Publisher и объектом «Регистрация», который является внутренней частью агрегата SocialAccount.

Эти понятия болеечем просто правила, у них есть причины.Вам необходимо проанализировать, что на самом деле означает агрегат, понять, что на самом деле говорят правила и что они на самом деле значат, почему они существуют в первую очередь.Затем переоцените ваши отношения и составьте соответствующие определения.

0 голосов
/ 10 декабря 2010

Сначала нам понадобится абстракция для инкапсуляции ссылок в модели.

AGGREGATE - это кластер связанных объектов, которые мы рассматриваем как единое целое для целей изменения данных.

Каждый AGGREGATE имеет корень и границу.Граница определяет, что находится внутри АГРЕГАТА.Корень - это отдельная особая сущность, содержащаяся в АГРЕГАТЕ.Корень является единственным членом AGGREGATE, на который внешним объектам разрешено хранить ссылки, хотя объекты внутри границы могут содержать ссылки друг на друга.СУЩНОСТИ, отличные от корня, имеют локальную идентичность, но эта идентичность должна различаться только в СУММЕ, потому что ни один внешний объект никогда не сможет увидеть его вне контекста корневого СУЩНОСТИ.

что вы думаете об этом Ssyphus

...