, имеющих проблемы с реальной мировой логикой в домен DDD
, несмотря на то, что он изучил дизайн домена в течение длительного времени, теперь есть еще некоторые основы, которые я просто понимать.
Похоже, что каждый раз, когда я пытаюсь разработать богатые доменного слоя , мне все еще нужно много доменных услуг или толстым уровнем приложений , а также Я в конечном итоге с кучей близко-анемичных доменных сущностей без реальной логики в них, кроме «GetTotalamount» и тому подобное. Ключевой проблемой заключается в том, что объекты не знают о внешних вещах, и плохая практика впрыскивает что-либо в субъектам.
Позвольте мне дать несколько примеров:
1. Пользователь подписывает для сервиса. Пользователь сохраняется в базе данных, файл генерируется и сохраняется (необходимо для учетной записи пользователя), и отправляется письмо подтверждения.
Пример с подтверждающим письмом был сильно обсужен в других потоках, но без реального заключения. Некоторые предлагают положить логику в службу приложений , которые получают Emailсервис и и , но в этом случае мне нужно будет иметь интерфейсы услуг инфраструктуры , введенные , введенные из инфраструктурного слоя . Но тогда у меня будет деловая логика за пределами домена, верно? Другие предлагают создать службу домена , которые получают инфраструктурные услуги внутри Доменный слой ( IEMailService и IFILESERVICE ), который также не выглядит слишком хорошим (потому что уровень домена не может ссылаться на слой инфраструктуры ). И другие предлагают реализацию доменных событий Уди Дахана , а затем, имея электронную почту и файловый сервис, подписывайтесь на эти события. Но это похоже на очень свободную реализацию - и что произойдет, если услуги потерпят неудачу? Пожалуйста, дайте мне знать, что вы считаете правильным решением здесь.
2. Песня куплена из цифрового музыкального магазина. Корзина опустошена. Покупка сохраняется. Служба платежей называется. Подтверждение по электронной почте отправляется.
Хорошо, это может быть связано с первым примером. Вопрос здесь есть, который несет ответственность за организацию этой транзакции? Конечно, я мог бы поставить все в контроллер MVC с инъекционными службами. Но если я хочу, чтобы настоящая DDD вся бизнес-логика должна быть в домене. Но какой объект должен иметь метод «покупки»? SONG.PUCKASE () ? Заказать. Круждается () ? OrderProcessor.purchase () (Доменная служба)? ShoppingCartservice.purchase () (Служба приложений?)
Это так, где я думаю, что очень трудно использовать реальную бизнес-логику внутри объектов домена. Если это не очень хорошая практика, чтобы ввести что-либо в сущности, как они могут когда-либо делать другие вещи, чем проверять свой собственный (и его совокупность) государства?
Я надеюсь, что эти примеры достаточно ясны, чтобы показать проблемы, с которыми я имею дело.