Агрегаты и хранилище. Как определить агрегаты? - PullRequest
4 голосов
/ 04 августа 2009

Недавно я рассматривал шаблон репозитория как способ очистки всех деталей постоянства под ковром, когда речь идет о клиентском коде. При чтении кажется, что репозиторий является / может быть [обычно?] Ответственным за агрегаты, а не только за простые классы.

Это имеет смысл для меня, поскольку у вас может быть класс, определяющий Сообщений , и другой, определяющий Комментарии . Это делает идеальным кандидатом для совокупности, так как эти два очень тесно связаны. Однако, как бы я представлял класс Users и его связь с его или ее Posts ?

Имеет ли смысл объединять пользователей с помощью сообщений / комментариев или объединять пользователей в отдельности и просто связывать их по старым добрым ссылкам?

Я сам пытался найти ответ с помощью Google, но многие примеры, которые я нахожу, просто автономны. т.е. Сообщений / комментариев или, может быть, Order и OrderLine и т. д. Я не могу найти ничего, что показывает, как другие связанные классы сочетаются друг с другом.

Я не применяю это к чему-то конкретному, хотя PHP или Java / C #, вероятно, были бы областью, в которой я хотел бы использовать эти идеи. В любом случае, я просто исследую и пытаюсь обдумать некоторые из этих идей и концепций, прежде чем убежать и создать монстра. :)

Спасибо, что уделили время.

1 Ответ

3 голосов
/ 05 августа 2009

Шаблон репозитория довольно слабо определен и не обязательно имеет какое-либо отношение к Агрегированному шаблону. Однако если вы подпишетесь на DDD, то да, репозитории являются уникальными для агрегатов.

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

В вашем случае, когда вы удаляете сообщение, я предполагаю, что вы также удалите комментарии, но не пользователя, создавшего сообщение, или пользователей, которые прокомментировали его. Следовательно, вы правильно определили совокупность записей / комментариев, но не имеет смысла группировать пользователей в эту совокупность.

Пользователи, будучи своей собственной совокупностью, могут содержать отношение ко всем своим сообщениям, поскольку Post - это совокупный корень. Вы также можете реализовать этот метод в PostRepository, чтобы получить все сообщения от данного пользователя. Надеюсь, это поможет!

...