Домен управляемый дизайн - Как собрать пошаговую игру

Question

Я разрабатываю игру в корпоративном бизнесе. Это пошаговая игра.

Инварианты:

а) В игре есть как минимум два игрока, дата начала и др. свойства.

б) Каждый игрок играет ход внутри игры.

в) Член когда присоединяется к игре, становится игроком.

d) Участник может быть игроком в 0-н игры.

Моя главная проблема - как объединить понятия.

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

Позже возможно, что Игра является корнем другого агрегата, включая игрока и ход. Что бы я мог обеспечить:

• инвариант а) когда я его создаю.
• инвариант б) агрегат имеет все, что нужно внутри агрегата для удовлетворения инвариантов.
• инвариант c) => нет ответственности этого агрегата

Я хотел бы услышать ваши подходы, потому что я действительно застрял.

Answer 1

Вы правильно поняли, с 2 агрегатами, но теперь вам нужно понять, почему.

Агрегат участников владеет данными и поведением участников. Что означает член, как стать участником, когда он может изменить свое имя, когда его можно разблокировать и т. Д.

Игровой агрегат владеет правилами игры и двумя игроками. В нем есть все данные, необходимые для защиты его инвариантов и отображения в пользовательском интерфейсе. Инварианты, которые он защищает:

1. как минимум два разных игрока должны существовать до начала игры, и один участник может играть только один раз в одной и той же игре
2. каждый игрок делает ход один за другим
3. когда игрок вышел из игры, он больше не может двигаться
4. и т. Д.

Для защиты второго инварианта в игре есть состояние turn, которое является указателем на следующего игрока. Но тут возникает интересный вопрос: что такое Player, как его можно представить в коде?

Игрок является указателем на одного из Участников. В нем есть все атрибуты, которые необходимы игровому агрегату или пользовательскому интерфейсу. Игровому агрегату нужен свой идентификатор для защиты первого инварианта (для обнаружения дублирующих идентификаторов), для загрузки всех игр, в которые играет Участник, и для отображения в пользовательском интерфейсе имени Игрока, чтобы другие игроки могли знать, с кем они играют.

Игрок выглядит как сущность, потому что у него есть идентификатор и другое свойство, это имя, но это не потому, что он не владеет ни именем, ни поведением для него: когда и как член может изменить его. имя контролируется Агрегатом Участника, имя Игрока обновляется без Игрока, чтобы иметь слово об этом, возможно, в фоновом режиме.

С точки зрения Игры, игрок - это простой объект, неизменный, с идентификатором и именем как string. Это идеальный кандидат для объекта Value.

Таким образом, хотя Элемент является Агрегированным корнем (который является типом сущности), Игрок, имеющий тот же идентификатор и имя, что и Элемент, является не сущностью, а объектом значения.

Answer 2

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

Оправдание заключается в том, что для выяснения того, является ли история игры внутренне непротиворечивой, необходимо уметь видеть всю историю "вместе", чтобы вы могли обнаружить противоречия.

Чтобы увидеть это, нужно заметить, что два разных членства обычно не имеют зависимостей друг от друга, поэтому для них имеет смысл быть разными экземплярами совокупности. Если игра должна совместно использоваться двумя участниками, то она не может принадлежать ни одному из участников, поэтому это должен быть какой-то третий агрегат, который отслеживается отдельно.