Блог

Модель домена

У события (развлечения, спорт, викторина) много проблем (забавные проблемы, спорт, проблемы, связанные с викториной).

Проблема имеет много решений (каждая команда загружает решение), решение имеет много оценок (каждый судья публикует оценку).

Первоначальная цель — начать с одного типа события (например, события викторины), и у него есть несколько проблем и решений. Судья может оценивать решения.

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

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

хотите сделать как микроуслуги с весенней загрузкой с mongodb.

Что я сделал до сих пор

У меня есть

абстрактный класс для события, проблемы, решения и оценки (на основе свойства оценки типа события может измениться).

Регистрация домена с командой, проблемой и решением в качестве ссылочного свойства.

Как действовать дальше и делаю ли я это в настоящее время?

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

Как только это будет сделано, я всегда стараюсь сделать вещи как можно более универсальными, поэтому, когда я начинаю смешивать все части, они могут взаимодействовать независимо от их реального состояния. То есть я пытаюсь наладить взаимодействие между частями, просто используя их интерфейсы / абстрактные классы (одна проблема -> Много решений, одна команда -> Одно решение и т.д.). Я не вижу информации о тех свойствах, о которых вы говорите, но я полагаю, что они могут относиться к общей проблеме и просто настраиваться для каждого конкретного типа проблемы (но не объявлены).

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

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

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

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

В качестве резюме:

1. Попробуйте выделить общий фактор каждой части и то, как он взаимодействует с другими.
2. Кроме того, постарайтесь обеспечить взаимодействие независимо от конкретных типов и свойств, предоставляя как можно больше информации в общих интерфейсах (очевидно, если это имеет смысл).
3. Если это невозможно, можно использовать абстрактную фабрику, которая позволяет вам создавать внутренние взаимосвязи с учетом деталей реализации без привязки внешних частей.

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