Где я должен поместить значение создания объекта logi c, если это требует доступа к внешнему API (Domain Driven Design) - PullRequest
Новая
       70

Где я должен поместить значение создания объекта logi c, если это требует доступа к внешнему API (Domain Driven Design)

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

У меня есть сущность, скажем, это UserAccount. UserAccount имеет объект значения, который является MembershipID. MembershipID становится объектом значения, потому что внутри него есть бизнес-логика c, а не просто строка. Но здесь есть сложная ситуация.

Чтобы сгенерировать идентификатор участника, мне нужно взять случайную строку и метку времени создания учетной записи пользователя. Затем эти два значения отправляются во внешний REST API, и его успешный ответ будет содержать MembershipID.

Этот лог создания c объекта значения включает в себя вызов внешнего API, который относится к уровню инфраструктуры. Фабрика и Хранилище пришли мне на ум в первую очередь как место, где можно поместить логи создания c, но эти два предназначены для сущностей, а не для объектов значения. Так, где я должен поместить это создание логи c объекта значения и не нарушая DDD?

1 Ответ

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

Базовая c идея: приложение (не модель домена ) отвечает за выборку данных из внешнего мира модели.

Чтобы создать идентификатор участника, Мне нужно взять случайную строку и метку времени, когда пользовательский аккаунт создан. Затем эти два значения отправляются во внешний REST API, и его успешный ответ будет содержать MembershipID.

По сути, у вас есть нечто, похожее на функцию, которая принимает случайное начальное число и отметка времени в качестве аргумента и возвращает членство.

Эта функция будет реализована компонентами приложения, которые знают, как говорить REST, где размещены внешние API и т. д.

Эта функция будет вызываться , как правило, одним из двух способов. Либо приложение выполнит работу, а затем передаст значение в модель домена ... 

m = membershipId(domainModel.randomSeed, domainModel.createdTime)
domainModel.assignMembershipId(m)

ИЛИ мы передадим возможность в модель домена, и пусть модель решит, вызывать ее или нет: 

DomainModel::doIt(membershipId) {
    this.membershipId = membershipId(this.randomSeed, this.createdTime)
}

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

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

прямо сейчас я помещаю внешний API, обращающийся к logi c, внутри доменная служба

Используя верхний стиль, вы реализуете логи доступа c в службе приложений , а не в доменной службе . Получение данных «откуда-то еще» - это не задача моделирования домена, а проблема сантехники.

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

...