Чистая архитектура: выходной порт UseCase
У меня есть вопрос, касающийся "порта вывода варианта использования" в чистой архитектуре дяди Боба.
На изображении дядя Боб описывает порт как интерфейс. Мне интересно, должен ли это быть таким образом или вызванный Use Case Interactor мог бы также возвращать "простое" значение. В любом случае уровень приложений и бизнес-правил определит свой интерфейс, который должен использовать уровень интерфейсных адаптеров. Поэтому я думаю, что для простых вызовов простой возврат значения не нарушит архитектурную идею.
Это правда?
Кроме того, я думаю, что этот интерфейс выходного порта, реализованный докладчиком, должен работать как шаблон Observer. Ведущий просто наблюдает за интерактором для соответствующих "событий". В случае.NET, где события являются первоклассными гражданами, я думаю, что использование одного из них - та же идея.
Совместимы ли эти мысли с идеями Чистой Архитектуры?
1 ответ
Howzit OP. Я вижу, что ваш вопрос все еще остается без ответа после стольких лет, и я надеюсь, что мы сможем обсудить это и внести некоторую ясность. Я также надеюсь, что правильно понимаю ваш вопрос. Имея это в виду, вот как я вижу решение:
Короткий ответ: интерактор варианта использования должен иметь возможность возвращать простое значение (под которым я подразумеваю string, int, bool и т. Д.) Без нарушения каких-либо архитектурных правил.
Если мы рассмотрим луковичную архитектуру, которая очень похожа на чистую архитектуру, идея состоит в том, чтобы инкапсулировать основную бизнес-логику в центре архитектуры, в домене. Соответствующая концепция в чистой архитектуре - это сущности и варианты использования поверх них. Мы делаем это, потому что хотим последовательно определять наше понимание бизнеса при написании бизнес-правил.
Адаптеры интерфейса позволяют нам преобразовать внешний мир в наше понимание. Нам нужен контракт в нашем домене (варианты использования или объекты), который гарантирует, что мы получим то, что нам нужно, из внешнего мира, не зная каких-либо деталей реализации. Нам также все равно, как это назовет внешний мир, мы конвертируем их понимание в наше.
Обычный способ сделать это - определить интерфейс в домене, чтобы установить контракт, в котором говорится, что мы ожидаем дать «x», а затем вы должны сообщить нам, что такое «y». Затем реализация может находиться вне домена.
Теперь перейдем к сути вашего вопроса. Предположим, что суть нашего приложения - отслеживать какой-то сложный процесс с различными этапами. На одном из этих этапов нам нужно отправить данные нескольким внешним сторонам, и мы хотим сохранить какую-то ссылку для целей аудита. В таком случае наш интерфейс может находиться в домене и указывать, что мы отправляем наш сложный объект какой-либо стороне, и мы ожидаем возврата строковой ссылки. Затем мы можем использовать эту строковую ссылку и запустить какое-то событие домена и т. Д. Реализация может находиться полностью вне домена и вызывать внешние API-интерфейсы и делать это, но на наш основной домен это не влияет. Следовательно, возврат простого значения не влияет на архитектуру. Может также произойти и обратное вышеописанному сценарию. Мы можем сказать, что у нас есть какой-то ссылочный идентификатор,а внешний мир должен вернуть нам наше понимание некоторого объекта.
По второй части вашего вопроса. Я предполагаю, что это зависит от самого варианта использования. Если вы представите какую-то идею и вам нужно постоянно на нее реагировать, будут задействованы события предметной области, и у вас будет структура, очень похожая на шаблон наблюдателя. .NET очень хорошо инкапсулирует события и очень хорошо сочетается с чистой архитектурой и дизайном, управляемым доменом.
Пожалуйста, дайте мне знать, есть ли в вышеизложенном смысл или я могу прояснить это каким-либо образом.