Комментарии 5
Спасибо за статью.
Но разве UseCase должен преобразовать Markdown в HTML?
Что если нам понадобится, в будущем, REST API для блога или мы захотим читать блог через терминал с диска со специальным форматированием для него?
Думаю таким должен заниматься UI слой, получая только модель с данными.
Статья хорошая, но я не понял, зачем так все усложнять с точки зрения терминологии.
Юзкейсы – в этих объектах реализуется каждое из действий, совершаемых в системе
Можно было так и назвать - Действия
Сущности – это объекты и правила бизнес-логики в наиболее чистом виде
Можно было так и назвать - Объекты
Порты – это просто интерфейсы, применяемые при работе с юзкейсами.
Можно было так и назвать - Интерфейсы
Тогда сложный текст становится гораздо проще для восприятия:
"Для всех ядер характерно поведение такого рода: действие вызывается из другого слоя, получающего некоторые данные, после чего из долговременного хранилища загружается некоторый объект, и это делается при помощи интерфейса. После этого код работает с объектом, генерируя его новое состояние. В этом процессе могут использоваться другие интерфейсы и объекты. В конце концов, объект вновь долговременно сохраняется в коде действия с использованием интерфейса, после чего возвращается ожидаемый результат."
Тоже делал такое, дико удобно разрабатывать и писать тесты. Но есть нюансы, о которых узнаешь только начав работать с этим:
Много маппингов структур между слоями
Нужен DI-контейнер, иначе при развитии проекта становится сложно уже не в бизнес логике, а в инициализации зависимостей
Поход репозиториев требует какого-то решения для транзакций. Зачастую это усложняет код, приводит к утечке абстракции в слой бизнес-логики и при определенных реализациях также может замедлить выполнение
Зачастую в юзкейсах есть общий код, который надо куда-то выделить. При этом не хочется каждый раз в функции пробрасывать зависимости
Как реализовать паттерн outbox в репозитории без утечки абстракции и кросс зависимости между адаптерами?
Это только то, что вспомнил. Жаль никто не пишет про это. Возможно, напишу как-нибудь статью.
Спасибо за статью, но мне она ничем не помогла.
Я плохо разбираюсь в архитектурах, как раз начал этот вопрос изучать, попутна читая книгу по чистой архитектуре.
И сколько статей не читал, все они разные, написаны по разному и делают противоположные выводы.
Почему все примеры с архитектурами пишутся на каких то супер простых сервисах, у вас тут даже валидаций нет.
Применение чистой архитектуры в Go