Я пытаюсь понять, как правильно использовать шаблон репозитория. Центральная концепция "Агрегатного корня" продолжает расти. При поиске как в Интернете, так и в Qaru для получения справки о том, что представляет собой совокупный корень, я продолжаю находить обсуждения о них и мертвые ссылки на страницы, которые должны содержать базовые определения.
В контексте шаблона репозитория , что является агрегированным корнем?
В контексте шаблона репозитория совокупные корни являются единственными объектами, которые ваш клиентский код загружает из репозитория.
Репозиторий инкапсулирует доступ к дочерним объектам - с точки зрения вызывающего абонента он автоматически загружает их, либо в то же время, когда загружается корень, либо когда они действительно нужны (как при ленивой загрузке).
Например, у вас может быть объект Order, который инкапсулирует операции с несколькими объектами LineItem. Ваш клиентский код никогда не будет загружать объекты LineItem напрямую, а только Order, который их содержит, который будет являться агрегирующим корнем для этой части вашего домена.
От Evans DDD:
AGGREGATE - это кластер связанных объектов, которые мы рассматриваем как единицу с целью изменения данных. Каждый AGGREGATE имеет корень и границу. Граница определяет, что находится внутри AGGREGATE. Корень - это единственный, определенный ENTITY, содержащийся в AGGREGATE.
и
Корень является единственным членом AGGREGATE, что внешним объектам разрешено удерживать ссылки на [.]
Это означает, что совокупные корни являются единственными объектами, которые могут быть загружены из репозитория.
Пример - это модель, содержащая объект Customer и объект Address. Мы никогда не будем обращаться к объекту Address непосредственно из модели, поскольку это не имеет смысла без контекста ассоциированного Customer. Таким образом, мы могли бы сказать, что Customer и Address вместе образуют совокупность и что Customer является совокупным корнем.
Агрегатный корень - сложное имя для простой идеи.
Хорошо разработанная диаграмма классов инкапсулирует ее внутренности. Точка, через которую вы получаете доступ к этой структуре, называется aggregate root.
Внутренние части вашего решения могут быть очень сложными, но пользователь этой иерархии будет просто использовать root.doSomethingWhichHasBusinessMeaning().
Проверьте эту простую иерархию классов
Как вы хотите покататься на своем автомобиле? Выберите лучше api
Вариант A (он как-то работает):
car.ride();
Вариант B (пользователь имеет доступ к классам inernals):
if(car.getTires().getUsageLevel()< Car.ACCEPTABLE_TIRE_USAGE)
for (Wheel w: car:getWheels()){
w.spin();
}
}
Если вы считаете, что вариант A лучше, то поздравления. Вы получаете основную причину aggregate root.
Агрегированный корень инкапсулирует несколько классов. вы можете манипулировать всей иерархией только через главный объект.
Представьте, что у вас есть компьютерный объект, этот объект также не может жить без его объекта Software и аппаратного обеспечения. Они образуют агрегат Computer, мини-экосистему для компьютерной части домена.
Агрегированный корень является материнским сущностью внутри совокупности (в нашем случае Computer), распространенная практика заключается в том, что ваш репозиторий работает только с сущностями, являющимися агрегированными корнями, и этот объект отвечает за инициализацию других объектов.
Рассмотрим совокупный корень в качестве точки входа в совокупность.
В коде С#:
public class Computer : IEntity, IAggregateRoot
{
public Hardware Hardware { get; set; }
public Software Software { get; set; }
}
public class Hardware : IEntity { }
public class Software : IValueObject { }
public class Repository<T> : IRepository<T> where T : IAggregateRoot {}
Имейте в виду, что аппаратное обеспечение, скорее всего, будет ValueObject тоже (не имеет собственного идентификатора), рассмотрите его только как пример.
Если вы придерживаетесь подхода, основанного на базе данных, вы объединяете корень, как правило, это таблица с 1 стороны отношения 1-много.
Наиболее распространенным примером является Person. У каждого человека много адресов, один или несколько платежных ведомостей, счета-фактуры, записи в CRM и т.д. Это не всегда так, но в 9/10 раз.
В настоящее время мы работаем над платформой для электронной коммерции, и у нас в основном есть два совокупных корня:
Клиенты поставляют контактную информацию, мы присваиваем им транзакции, транзакции получают позиции и т.д.
Продавцы продают продукты, имеют контакт с людьми, о нас, о специальных предложениях и т.д.
Об этом заботятся репозитарий Клиента и Продавца соответственно.
Внутри агрегата есть сводный корень. Агрегатный корень является родительским Entity ко всем другим объектам и объектам Value в агрегате.
Репозиторий работает на основе совокупного корня.
Более подробную информацию можно найти здесь.
Дин:
В контексте репозитория Агрегатный корень является сущностью без родительской сущности. Он содержит нуль, одно или много дочерних объектов, существование которых зависит от родителя для его идентичности. Это отношение "Один ко многим" в репозитории. Эти дочерние объекты представляют собой простые агрегаты.
В Erlang нет необходимости проводить различие между агрегатами, как только совокупность составлена структурами данных внутри состояния, а не OO-композиция. Пример: https://github.com/bryanhunter/cqrs-with-erlang/tree/ndc-london
Агрегат означает сбор чего-то.
root похож на верхний node дерева, откуда мы можем получить доступ ко всему, как <html> node в документе веб-страницы.
Blog Analogy, пользователь может иметь много сообщений, и каждый пост может иметь много комментариев. поэтому, если мы выберем любого пользователя, тогда он может действовать как root, чтобы получить доступ ко всем связанным сообщениям и дополнительным комментариям этих сообщений. Все они вместе называются коллекциями или Агрегированные
Агрегат - это то, где вы защищаете свои инварианты и согласованность усилий, ограничивая свой общий доступ к ресурсу. Не забывайте, что агрегат должен разрабатывать ваши бизнес-правила и инварианты вашего проекта, а не отношения к базе данных. вам не следует вводить какой-либо репозиторий, и запросы не допускаются.