А можно на конкретном примере?

приложение моделирует процессы реального мира. если процессы поставлены криво - то это повлечет и кривую реализацию. Например: я на кассе оплачиваю покупку в магазине, сначала заказ должен быть сформирован - кассир пробивает все позиции, а потом спрашивает как я будут оплачивать. * Фактически сначала создается заказ, потом происходит процесс попытки оплаты - сам процесс попытки оплаты также можно отразить в виде объекта предметной области. * Процесс попытки оплатить - имеет свой идентификатор, имеет id заказа, и имеет свой тип(оплата налом, банковской картой, по qr коду и т.д.). * В такой ситуации будет событие - создание заказа(и там не будет ничего про способ оплаты), и будет событие инициации процесса попытки оплатить (попыток может быть несколько, например на карте не было денег, попробовал другой картой) Если процесс в реальном мире поставлен так что кассир меня сначала спросит про способ оплаты, а потом начнет пробивать позиции в заказе - то да, придется отражать это в приложение. Т.е. заказ будет содержать в себе данные о способе оплаты - и это породит много веселого, например если заказ был создан с типом оплаты - "наличка", налички не хватило, клиент начал платить картой. Что должно меняться и в какой последовательности - для меня имхо это ад и содомия. Вариант когда в реальности процесс поставлен корректно, но у разработчика не хватило компетенции отразить это в коде - это отдельный случай.

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

А что я оплачиваю? Т.е. вот есть факт оплаты, но за что именно были получены деньги?

выбор способа оплаты и оплата - не одно и то же. Выбрать способ оплаты можно и до начала покупок вообще при регистрации даже какой-нибудь

так выбор способа оплаты - к чему будет относится?

скорее всего к оплате

а что это такое? какое отражение это имеет в реальном мире?

А выбор способа оплаты вообще имеет смысл без или до оплаты?

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

А способ оплаты чего?

заказа. Прикол в том, что тебе для этого нужен только идентификатор. Если у тебя есть идентификатор заказа - значит ли это, что заказ уже существует?

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

нет, если идентификатор есть, то заказа может ещё и не быть. Что мешает создать идентификатор? Но можно наверное и то как ты описываешь это сделать. Но тогда тебе ничего не должно мешать создать заказ до выбора оплаты

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

а как может получиться что существует идентификатор сущности, но нет самой сущности? что тогда этот идентификатор идентифицирует?

ну тут уже можно подумать на тему нейминга. Может созданный заказ с одним идентификатором - это и не заказ вовсе, а сессия покупок например. Она может иметь тот же идентификатор, что и будущий заказ

ну просто вызываешь функцию создания UUID и всё

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

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