Вопрос API, управляемый доменом

Question

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

Итак, мой первый, хотя мой агрегат содержит объект регистрации, четырехзначный ценностный объект (который содержит название команды и 4 объекта ценностей игрока).

при разработке API я думаю следующий псевдокод:

Registration reg = new Registration();

Foursome foursome = reg.CreateFoursome("My Team");

foursome.Player1.Assign("John Doe", 5, ShirtSize.XL);

reg.Register();

У меня вопрос: один из внутренних компонентов совокупности подвергается воздействию клиентского кода, поэтому я открываю себя для проблем? какие-нибудь недостатки с этим простым дизайном или альтернативой apis?

любая помощь была бы великолепна, так как я сейчас нахожусь в состоянии аналитического паралича!

спасибо

Answer 1

Давайте начнем с Агрегат определение :

Кластер связанных объектов, которые рассматриваются как единое целое для цель изменения данных . Внешние ссылки ограничены одним член Агрегата, обозначенный как корень. Набор консистенция правила применяются в пределах Агрегата.

Агрегат - это группа объектов, которую вы не хотите, чтобы несколько пользователей редактировали одновременно, поскольку она может нарушать инварианты домена. Агрегат также является единицей жизненного цикла. Трудно ответить на ваш вопрос, не зная, каковы эти инварианты, согласованность и правила жизненного цикла. Было бы плохо создавать две четверки на одной и той же регистрации? Будет ли четверка с неназначенным игроком 1 недействительной / непоследовательной? Не вызовет ли объект «Регистрация при регистрации» объект? Если один из ответов верен, то вы не должны выставлять свои объекты таким образом. Этот код должен быть скрыт внутри вашей совокупности.

Также похоже, что Foursome не является Value Object , потому что он изменчив. Это может быть объект, который должен быть защищен регистрацией совокупного корня.

// PlayerInfo is a value object
public static Registration CreateNew(String foursomeName, PlayerInfo player1, ...) {
    if (foursomeName == null) {
        throw new ArgumentNullException("foursomeName");
    }
    if (player1 == null) {
        throw new ArgumentNullException("player1");
    }

    Registration reg = new Registration();

    Foursome foursome = reg.CreateFoursome("My Team");

    foursome.Player1.Assign(player1);

    if(player2 != null) {
        foursome.Player2.Assign(player2);
    }
    reg.Register();

    // return consistent and valid Registration instance
    return reg;
}

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

Answer 2

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

Возьмем, к примеру, ваш класс FourSome, который, как я полагаю, состоит из четырех игроков.Могли бы вы вместо этого иметь класс Team, который имеет ограничение на размер, так что коллекция Players может быть ограничена таким количеством игроков?Должен ли быть класс Player (или, возможно, это тип Player1?)?

Ответы на эти вопросы будут влиять на расширяемость вашей системы.

Я рекомендую вам написатькаждый из ваших сценариев в тесты (вы можете использовать пользовательские истории или варианты использования, но разработчики любят писать код), и, когда вы пишете тесты, заполните реализацию класса Registration, Player и Foursome / Team, чтобы тесты были успешными.,По мере расширения вашей системы ваши тесты будут меняться, как и ваш дизайн.

После добавления 1:

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

В ходе этого процесса вы можете непреднамеренно представитьнедостатки дизайна.Например, FourSome, технически, это тип команды, ограниченный четырьмя игроками.Имеет ли смысл выводить класс из Team и устанавливать лимит в четыре игрока, или имеет смысл накладывать ограничения на Team?Это дизайнерское решение, определяемое ... вашими бизнес-правилами и вами.Является ли ошибкой использование одного подхода над другим?Время покажет, так как вам потребуется постоянно проводить рефакторинг для расширения системы.

В процессе проектирования вы найдете много шаблонов, которые могут упростить процесс проектирования, но у нового дизайнера обычно нетопыт, чтобы узнать, когда их использовать.Если вы делаете, слава тебе.Вы не найдете идеальный дизайн в самый первый раз, когда вы проектируете.Я все еще оглядываюсь назад (15 лет назад) на проекты, которые я думал, были удивительными, и качаю головой в моем юном изобилии.

Вы должны описать свою проблему (себе или на бумаге).Подчеркните существительные.Это ваши кандидаты в классы.Расскажите историю для каждого взаимодействия пользователя с системой, и глаголы должны помочь вам понять, какие методы используются в каждом классе.Избегайте использования Регистрации для выполнения всей работы, но разделяйте ответственность классов там, где это необходимо.Например, вы можете добавить игрока в команду, или вы можете добавить игрока в команду.Определение, где лежит эта ответственность, должно руководствоваться (но не диктоваться) ПСП, наряду с другими рекомендациями по проектированию.

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

После редакции 2:

Я думаю, вы слишком много читаете под руководством Эрика Эвана.Я не верю, что он говорит, что вы не можете выставить Игрока из Четверки.