Как структурировать разделение и пространства имен в CQRS? - PullRequest
Новая
       104

Как структурировать разделение и пространства имен в CQRS?

1 голос
/ 24 апреля 2020

Я ищу совет о том, как структурировать пространства имен в структурированном приложении CQRS.

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

В настоящее время структура имеет следующие папки, каждая из которых содержит реализацию: 

Application
+ Api
+ Cli
+ Web
Domain
+ Action (Command and Command Handlers in one - we are not using a CommandBus) 
+ Event
+ Model
+-- Project
  |-- Project.file
  |-- ProjectRepository.file
Infrastructure
+ Consumer (Projections and ProcessManagers)
+ EventStore
+ Persistance (Denormalized read side)
+-- Project
  |-- SqlProjectRepository.file
Common (Supporting namespace)

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

Нет перекрытия в агрегатах стороны запроса и стороны команды.

При рефакторинге для разделения, где должен быть сделан срез?

Предложение 1

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

Предложение 2

Срез, который создается только на слое домена, так что Каждая сторона содержит (довольно анемичные c) сущности модели чтения, а командная сторона содержит события, совокупность источников событий root и более.

Пожалуйста, сделайте 3-е предложение, если мое не применимо , Спасибо.

Ответы [ 2 ]

1 голос
/ 24 апреля 2020

В настоящее время в структуре есть следующие папки, каждая из которых содержит реализацию ...

Это прискорбно.

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

Не думаю, что я согласен с полным анализом Джимми Богарда здесь, но урок фокусировки на функциях важен

https://jimmybogard.com/vertical-slice-architecture/

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

0 голосов
/ 25 апреля 2020

Я использую этот подход - на основе CQRS и DDD, отмечая, что наш DDD распространяется на отдельное решение (. NET - веб-API для различных контекстов, ограниченных доменом).

Во-вторых, весь наш инфраструктурный код, обработка аутентификации и общий код - выполняется в частном менеджере пакетов, который удаляет некоторые проблемы из одного решения, мы добавляем его в StartUp (DI). Также обратите внимание, что мы используем EntityFramework в качестве нашей реализации БД.

Однако, учитывая то, что вот как я и моя команда выделяем CQRS и DDD. 

+ App
+- Command
+-- Application.Command
+-- Data.Command.EntityFramework
+-- Domain.Command

+- Query
+-- Application.Query
+-- Data.Query.EntityFramework
+-- Domain.Query

+ Build
+- Pipeline

+ Database
+- Data.Database.EntityFramework
+- Data.Database.Model

+ Test

Api (API app)
Cli
...