Как смоделировать совокупность компании, содержащую много пользователей
Теперь у бизнес-экспертов появилось новое требование: мы хотим показать список компаний в нашем инструменте администрирования и количество активных пользователей.
Пока кажется, что вы описываете отчет. В общем случае отчет представляет собой описание информации, которая была у вас когда-то в прошлом. Вспомните, что человек-читатель обычно сидит на расстоянии около наносекунды от экрана, а данные уже прошли миллисекунды, чтобы пересечь сеть.
Поэтому данные в отчете уже устарели.
Если вы не блокируете данные от изменений до тех пор, пока люди не закончат их просматривать, существует вероятность того, что изменение произойдет во время просмотра данных.
Так что вам, вероятно, нужно глубже изучить свои требования: во что обойдется бизнесу, если информация в отчете устарела на несколько дней/часов/минут/секунд?
(Например, если вы разрабатываете «ресурсы» REST, которые передают информацию в этом отчете, это предполагает, что бизнес будет просматривать кэшированные копии информации).
В тех случаях, когда устаревшие данные допустимы, вам обычно не нужно сильно беспокоиться об использовании отчета для разработки модели предметной области. Таким образом, вы создаете любую разумно производительную реализацию отчета, которую можете, и если задержка отчета неприемлема, вы изучаете планирование обновлений локально кэшированной копии отчета, чтобы вы могли ответить на запрос GET с помощью недавно подготовленной копии.
CQRS (Command Query Responsibility Separation) — полезный поисковый термин, если вы хотите исследовать эту идею.
Когда ответ важен для сохранения неизменности вашего домена (он же: наша обработка новой информации ограничена «количеством активных пользователей», а использование устаревших данных означает, что генеральный директор может быть отправлен в тюрьму)... теперь эти проблемы начинаются чтобы повлиять на нашу реализацию модели предметной области.
Плохая новость: проблема все еще сложная.
Хорошая новость: перспектива тюремного заключения (или аналогичных наказаний) значительно увеличивает бюджет, доступный для уточнения деталей.
На практике: точно так же, как отчет должен пересекать сеть, и, следовательно, отчет имеет миллисекундную давность, когда кто-то смотрит на него, так и информация, которая передается вам по сети. Поэтому случаи, когда нам нужно мгновенно интегрировать новую информацию, редки.
Решение 5 кажется наиболее близким к тому, как я могу себе это представить.
Моделирование домена в основном предназначено для обеспечения соблюдения правил и инвариантов. Но это часто может означать, что данные имеют такую форму, что их трудно запрашивать.
Это решается путем создания отдельной модели чтения, которая находится в форме, где такие запросы возможны и просты. Затем вы обновляете эту модель на основе событий, поступающих из домена.
Прикрепляю к посту несколько видео по теме: