Любите разбивать большие команды на более мелкие, если в этом нет необходимости в настоящее время?

Question

Любите разбивать большие команды на более мелкие, если в этом нет необходимости в настоящее время?

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

Счастливый сценарий использования (например, обобщенный):

Учитывая, что Пользователь, Корзина и CartItem существуют.
Пользователь может добавить CartItem типа X в корзину
Пользователь может указать (установить несколько параметров) CartItem Y
Пользователь может добавить CartItem типа Y
Пользователь может выбрать адрес из своих адресов (создание их является заботой
другого БК)
Пользователь может разместить заказ

Теперь, поскольку все это происходит во Frontend, мой единственный механизм доставки теперь — это некоторые необработанные данные из GraphQL. Должен ли я иметь на прикладном уровне несколько CreateNewOrderFromGraphQL с методом create ($ someGraphQLData); который просто создает относительно большой CreateNewOrderCommand (потому что он должен содержать адрес, CartItems, промо-код и т. д.) и передает его через командную шину в мою модель домена, которая создает весь заказ?

Или я должен думать о своей модели домена так же, как это делается во внешнем интерфейсе, и поэтому в моем CreateNewOrderFromGraphQL разбить большие необработанные данные GraphQL на отдельные команды, такие как CreateCartCommand, AddItemToCartCommand, CreateOrderCommand (который будет состоять из идентификатора корзины, идентификатора адреса и, возможно, некоторых детали), а затем вызвать их в последовательности?

Какие соображения я должен принять на это?

2

cqrs domain-driven-design php

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

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

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

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

Тележка может быть сделана как другая Aggregate, Он должен иметь такие команды, как CreateCartCommand а также AddItemToCartCommand, Или это можно сделать как CRUD, если нет реальных инвариантов.

Затем OrderAggregate может иметь PlaceOrderCommand, с элементами из корзины в качестве аргументов и AddressId а также UserId которые уже проверены на наличие на уровне приложений. это Aggregate защищает свои собственные инварианты, как total price <= some max value или проверьте состояние инвентаря (в случае, если инвентарь не находится в другом BC).

2