Чистая архитектура в Go-приложении. Часть 3

[gandjustas]

SQL-инъекция детектед:

    repo.dbHandler.Execute(fmt.Sprintf(`INSERT INTO customers (id, name)
                                        VALUES ('%d', '%v')`,
                                        customer.Id, customer.Name))

customer.Name это строка, никто кастомеру не помешает сделать имя

Bobby'); DROP TABLE customers;--

И самое интересное не показано:
1) Как выбирается OrderInteractor\AdminOrderInteractor
2) Как происходит обработка ошибок
В прошлом посте львиная доля кода уделена этим аспектам, а в текущем про них забыли начисто.

[trong]

Вы знаете, а мне нравится Ваш комментарий :))))

Из статьи:

Я уже слышу от тебя: это ужасный код! :) Много дублирования, нет обработки ошибок и несколько других дурнопахнущих вещей. Но смысл этой статьи ни в объяснении стилистики кода, ни реализации шаблонов проектирования — это все про АРХИТЕКТУРУ приложения, поэтому код написан так, чтобы на его примере было проще объяснить и было проще читать эту статью.

И тут Ваш комментарий: Ю-ху-у-у-у!!! Я нашел дурнопахнущий код!!!

Спасибо, Вы отлично подметили про SQL-инъекции!

Если же говорить про то, что не показано:
1) Это следует из логики кода, например в админской панели, видимо использовался бы AdminOrderInteractor, в интерфейсе пользователя — OrderInteractor
2) Давайте поговорим об этом — что Вам осталось не ясно в этом аспекте?

[gandjustas]

мне бы было стыдно столь плохой код публиковать, независимо от контекста. Разе в Go нету способа по-умолчанию не допускать таких проблем?

По основным вопросам
1) То есть опять будет копипаста? Ведь интерфейсы OrderInteractor и AdminOrderInteractor совпадают. Тогда в чем вообще смысл был разбиения на сценарии и сервисы? Если одному методу сценария соответствует ровно один метод сервиса.
2) Например как корректно обработать ошибку в слое «сценариев»? Сейчас код её игнорирует от слова вообще. Или вы не считаете что это важный архитектурный вопрос?

[trong]

Правильно ли я понимаю, что для Вас «хорошая архитектура» === «хороший код»?

[gandjustas]

Неправильно. Для меня хорошая архитектура помогает писать хороший код.
Архитектура сама по себе ценности не имеет. Если в приложении полно ошибок, уязвимостей, оно тормозит, то никакая хорошая архитектура не спасет. Поэтому архитектура нужна только для того, чтобы делать код лучше.

В статье код — говно полное, в чем хорошесть архитектуры — большой вопрос. В прошлом посте автор признал, что речь не о хорошей архитектуре, а вообще какбы словарик без претензий на хорошесть.

[trong]

В прошлом посте автор признал, что речь не о хорошей архитектуре, а вообще какбы словарик без претензий на хорошесть.

А покажите где такое было?

[gandjustas]

habrahabr.ru/post/270351/#comment_8653111

… Об этом статья. Она явно не для опытных разработчиков, просто базовые понятия логического разделения структур в коде.

Хотя может и не автор, я не вникал.

[taliban]

Вообще-то это мои слова, и имел ввиду я явно не «речь не о хорошей архитектуре, а вообще какбы словарик без претензий на хорошесть». Речь была именно об архитектуре минуя красивости кода. Если хотите конкретики, то представьте что статья написана в UML без строчки кода.

[mibori]

Разе в Go нету способа по-умолчанию не допускать таких проблем?

из коробки вроде нет. Но можно юзать ормы: github.com/avelino/awesome-go#orm

[trong]

И из коробки есть, если говорить о пакете database/sql

[claygod]

Для всех, кто прочёл все три части этой серии статей мной сделана простая визуализация кода, по возможности, вставленная в типичное графическое представление «чистой архитектуры». В вставленном в схему коде я заменил кое-что на многоточие, чтобы немного уменьшить его объем и вместить всё в формат А3.