DDD / CQRS для составного приложения .NET с несколькими базами данных

Question

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

Решение - это симулятор, который генерирует данные о производительности на основе текущей конфигурации.Администраторы могут создавать и изменять спецификации для моделирования.Тестеры устанавливают некоторые условия окружающей среды и запускают симулятор.Результаты регистрируются, агрегируются и представляются.

Решение состоит из 3 компонентных областей, каждая из которых имеет свои собственные сценарии использования, доменную логику и вспомогательную структуру данных.В результате модульная конструкция кажется привлекательной как способ отделить логику и разделить проблемы.

1. Первой областью будет административный аспект, который позволяет пользователям создавать и изменять спецификации.Это был бы тяжелый «модуль» CRUD.
2. Вторая область будет для выполнения моделирования.Модель предметной области будет аналогична первой области, но оптимизирована для выполнения моделирования, а не для предоставления удобной модели для редактирования.
3. Третья область - это отчетность.

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

Мой первый инстинкт - следовать этим строкам и создавать три модуля (сборки), которые инкапсулируютдоменный слой для каждой области.Должен ли я также иметь три отдельные базы данных?Может быть, больше трех для поддержки записи вместо чтения?

Я понимаю, что это может быть предпочтительным для CQRS, но я не уверен, как это сделать.Мне кажется, что CQRS предлагает набор внутренних процессов, которые перемещают данные.Но если это так, и постоянство данных является межсекторальным (как предполагает DDD), то не требует ли мой код доступа к данным осведомленности обо всех объектах домена?Если так, то есть ли преимущество в наличии отдельных модулей?

Наконец, ранее я не упомянул, что спецификации считаются «черновиками» до их публикации, что делает их доступными для моделирования.Мой PublishingService должен знать модель предметной области как для первой, так и для второй областей, чтобы при ответе на SpecificationPublishedEvent он мог прочитать спецификацию, перевести модель и сохранить ее для выполнения.Это заставляет меня думать, что у меня нет трех ограничивающих контекстов в конце концов.Или я что-то упустил в своем анализе?

Answer 1

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

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

Во-вторых, только потому, что в области происходят разные вещи, не обязательно есть причина, чтобы связывать их друг с другом. Я бы прочитал синюю книгу DDD, чтобы лучше понять, как выглядят BC.

Я не совсем понимаю ваш домен, но постараюсь дать несколько общих советов.

Начните с того, где вы говорили о вашем PublishingService. Я вижу совокупный корень спецификации, который принимает несколько команд, которые, вероятно, выглядят как CreateNewSpecification, UpdateSpecification и PublishSpecification.

События выглядят аналогично и, вероятно, кажутся избыточными: SpecificationCreated, SpecificationUpdated, SpecificationPublished. Какой тип отстой, но тяжелая модель CRUD не очень интересное поведение. Я бы также предложил найти автоматический способ справиться с изменениями модели / схемы в этом агрегате, что будет утомительно, если вы не используете генерацию кода или обрабатываете изменения динамическим * выделенным текстом * способом, который не требует от вас создавать новые события каждый раз.

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

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

Однако это не похоже на симуляцию, это обязательно тот тип AR, который также выиграет от Event Sourcing. По нескольким причинам:

1. Симуляция действительно требует только одну Команду, которая похожа на StartSimulation
2. Затем симуляция создает события в течение своего срока службы, которые представляют то, что происходит внутри с симуляцией
3. Кажется, что симуляция не получает никаких других команд, которые могут зависеть от текущего состояния симуляции
4. Симуляция не взаимодействует с несколькими клиентами / пользователями одновременно, и, как мы указали, она вообще не взаимодействует с

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