Комментарии 22
Копипаста, строки-литералы в коде, отсутствие проверок на получение по объектов Id (привет NRE), странное разделение на AdminOrderInteractor и OrderInteractor, хотя семантических отличий нет и разница только в одной проверке, странное копирование массива и это все называется «чистой архитектурой»?
Нет, это называется объяснение на максимально упрощенном примере, чтобы объяснять не код из 1000 строк а архитектурный подход.
Чистая архитектура и чистый код, это не синонимы. Вы с автором обсуждаете совершенно разные вещи. Архитектура не подразумевает наличие или отсутствие литералов в коде, она описывает взаимодействие кода.
А зачем нужна «чистая архитектура»? Я всегда думал что все архитектурные изыскания должны приводить к упрощению поддержки кода, разработки новых модулей и других улучшений, непосредственно влияющих на код. То есть хорошая архитектура — способ поиметь хороший код. Но здесь демонстрируется плохой код и это называется «чистой архитектурой»? В чем её чистота? Может есть тайный смысл, который никто не понял?
Да, это тайный смысл — писать об архитектуре, игнорируя стиль кода. Когда архитектор создает архитектуру проекта, он может не написать ни единой строчки кода. Возможно это прояснит ход моих мыслей. Диаграммы вместо кода вам были бы более понятны? Некоторым нет, а вот код все понимают.
Вы не ответили на вопрос. Какова цель архитектуры? Архитектура сама по себе не нужна. Как ответите на вопрос, то поймете что глупо говорить об архитектуре без кода. Кстати то что вы называете архитектурой является дизайном.
https://ru.wikipedia.org/wiki/Архитектура_программного_обеспечения Почитайте, пожалуйста, хотя-бы википедию. Я не могу общаться когда тупо гнут свою линию лишь бы не пасть лицом в говно. Цель архитекруты — правильное взаимодействие компонентов приложения, не зависимо от того какой код эти компоненты содержат. Имея хорошую архитектуру можно говнокодить безболезненно. Если у вас в команде есть опытны архитектор, он может спроектировать так приложение, что ваш говнокод в итоге можно будет безболезненно заменить на более красивый код и приложение будет все так же работать.
Возможно я ответил на вопрос, и все еще считаю что говорить об архитектуре без кода не глупо.
Возможно я ответил на вопрос, и все еще считаю что говорить об архитектуре без кода не глупо.
Что значит «правильное взаимодействие компонентов»? Зачем оно вам нужно?
Значит, например, что класс А будет взаимодействовать с классом В через посредника с интерфейсом С, и в итоге когда я хочу изменить логику взаимодействия между А и В, я просто заменяю класс-посредник, учитывая наличие интерфейса, код будет работать без изменений, а логика взаимодействия изменится. Это был базовый пример «что такое архитектура». Дальше Вы можете найти все в интернете. Спасибо за внимание.
Уже лучше. Вы попытались такой «архитектурой» уменьшить количество необходимых изменений. То есть одна из целей архитектуры — уменьшать количество изменений, так?
Тогда почему в примерах «чистой архитектуры» тонна копипасты, которая всегда количество изменений увеличивает?
Тогда почему в примерах «чистой архитектуры» тонна копипасты, которая всегда количество изменений увеличивает?
Есть класс «Кот», есть класс «Утка». Это не связанные классы, но у обоих есть метод «Дышать» в интерфейсах. Как думаете, если это вообще не основной метод из моего материала, буду ли я на нем акцентировать внимание? Нет, я скопипащу содержимое из одного класса в другой, и затем, когда нужно будет, я отрефакторю оба класса так, чтоб они работали без копипаста, и при этом, так как интерфейс обоих содержит метод «Дышать», который будет работать как и раньше, без изменения архитектуры приложения. Заметьте, я изменю в дальнейшем код, но без изменения архитектуры. Тоесть моя базовая архитектура взаимосвязи компонентов позволит избавиться от говнокода. Вот именно об этом статья, как связывать компоненты.
Это плохой пример. То что есть два одинаково названых метода не означает, что они делают тоже самое. Поэтому имеет смысл копировать куски кода и рефакторить потом или нет. Одного имени метода недостаточно.
Но в статье есть код, который и рабочий и полный. И очень хорошо видно, что функции OrderInteractor и AdminOrderInteractor делают одно и то же. Отличия в одной проверке и в формировании текста ошибки. Это значит, что при небольшом изменении требований придётся править в двух местах.
В чем «чистота» такой архитектуры? Вы считаете такой подход «связывания компонентов» правильным? Может всетаки есть тайный смысл так делать? Потому что по всем признакам в статье описана плохая архитектура, она увеличивает число изменений.
Но в статье есть код, который и рабочий и полный. И очень хорошо видно, что функции OrderInteractor и AdminOrderInteractor делают одно и то же. Отличия в одной проверке и в формировании текста ошибки. Это значит, что при небольшом изменении требований придётся править в двух местах.
В чем «чистота» такой архитектуры? Вы считаете такой подход «связывания компонентов» правильным? Может всетаки есть тайный смысл так делать? Потому что по всем признакам в статье описана плохая архитектура, она увеличивает число изменений.
Это был отличный пример того что два метода, которые мало меня интересуют можно проигнорировать, а затем, если они работают по разному, отрефакторить, хотя я явно указал на интерфейс. А в статье, как и в моем примере, OrderInteractor и AdminOrderInteractor в дальнейшем могут измениться (приставка Admin, как бы намекает), как ни странно, и если при замене содержимого, весь остальной код продолжит работать как и раньше, значит статья написана грамотно относительно архитектуры.
Могут измениться, а могут и не измениться. Сейчас плодить копипасту, потому что в будущем может что-то измениться — это признак «чистой» архитектуры? Я как раз чистоту понимал в прямо противоположном смысле.
Вы же знаете, что идеал это когда нечего убрать, а не нечего добавить. А в приведенном примере убирать много чего можно. И декомпозировать тоже. Например, явно нарушен принцип SRP, метод отвечает и за обработку заказа, и за формирование текстов ошибки. Как минимум обработку ошибок и легирование стоило бы отдельно вынести.
Я продолжаю не понимать что означает «чистая архитектура». По всем признакам, подтверждённым вашими словами, архитектура плохая получилась. Объясните пожалуйста в чем «чистота»?
Вы же знаете, что идеал это когда нечего убрать, а не нечего добавить. А в приведенном примере убирать много чего можно. И декомпозировать тоже. Например, явно нарушен принцип SRP, метод отвечает и за обработку заказа, и за формирование текстов ошибки. Как минимум обработку ошибок и легирование стоило бы отдельно вынести.
Я продолжаю не понимать что означает «чистая архитектура». По всем признакам, подтверждённым вашими словами, архитектура плохая получилась. Объясните пожалуйста в чем «чистота»?
О, вы начали говорить не про код а про архитектуру :) Теперь можно сказать главное — человек игнорирует что что считает менее приоритетным, из-за этого и копипаст появился итд. Вы ведь в курсе что всегда можно найти недочет? Любой код можно покритиковать. Человек говорит о чем-то, а то что считает не важным делает для виду. Вы считаете что это важно и критикуете места которые автор проигнорировал. Все просто.
Еще раз задаю тот же вопрос — в чем «чистота» описанной архитектуры?
Я вас об этом спрашиваю уже четвертый или пятый раз, но ответа до сих пор не увидел, вы все время ссылаетесь на «неважные детали», но я вас спрашиваю как раз про важные детали, а вы постоянно уходите от ответа. Уже и наводящие вопросы задавал, и напрямую спрашиваю, а все равно не вижу ответа чем же такая архитектура (на самом деле не архитектура, а дизайн) хороша.
Я вас об этом спрашиваю уже четвертый или пятый раз, но ответа до сих пор не увидел, вы все время ссылаетесь на «неважные детали», но я вас спрашиваю как раз про важные детали, а вы постоянно уходите от ответа. Уже и наводящие вопросы задавал, и напрямую спрашиваю, а все равно не вижу ответа чем же такая архитектура (на самом деле не архитектура, а дизайн) хороша.
Человек разделил архитектуру на 3 слоя: Домен, Сценарии и Интерфейсы. В первой части описал домены как просто структуры данных, в этой части описал сценарии и показал как он связывает прошлый слой с текущим. как взаимодействуют слои Домена со слоем Сценария. Это главное. Взаимодействие разных слоев абстракций между собой. Что конкретно они делают уже не так важно, важно какая структура какую содержит. Методы Items и Add можете смело очистить, это просто примеры использования.
Лично в моей терминологии слой Домен — модели, а Сценарии — сервисы. А у кого-то это одно и то же. Кто-то выбирает данные из базы и гоняет их по всему проекту описывая бизнес-логику прям в контроллерах. Кто-то вообще код пишет в одном файле весь. Об этом статья. Она явно не для опытных разработчиков, просто базовые понятия логического разделения структур в коде.
Лично в моей терминологии слой Домен — модели, а Сценарии — сервисы. А у кого-то это одно и то же. Кто-то выбирает данные из базы и гоняет их по всему проекту описывая бизнес-логику прям в контроллерах. Кто-то вообще код пишет в одном файле весь. Об этом статья. Она явно не для опытных разработчиков, просто базовые понятия логического разделения структур в коде.
Вы снова ушли от ответа на вопрос в чем чистота архитектуры.
Если только в этом:
Но это само по себе не является проблемой. Проблемой является плохая читаемость, большой объем изменений и высокая плотность ошибок. При этом в приведенном примере кода большой объем изменений и невысокая читаемость.
Если только в этом:
Кто-то выбирает данные из базы и гоняет их по всему проекту описывая бизнес-логику прям в контроллерах.
Но это само по себе не является проблемой. Проблемой является плохая читаемость, большой объем изменений и высокая плотность ошибок. При этом в приведенном примере кода большой объем изменений и невысокая читаемость.
Кто-то вообще код пишет в одном файле весь.Об этом в статье ничего нет.
Она явно не для опытных разработчиков, просто базовые понятия логического разделения структур в коде.Неопытыне разработчики имеют тенденцию копировать куски кода и паттерны из статей, которые читают. Поэтому показывая в статье копипасту, неудачные решения или просто плохой стиль наносится больший вред, чем польза от перечислений «базовых понятий».
Дохожу сам то такой архитектуры только тяжелым путем :(
Надо больше читать…
Надо больше читать…
Надеюсь будет продолжение несмотря на минусы…
Полагаю, что скоро выйдет следующая часть :)
Как и обещал — третья часть
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Чистая архитектура в Go-приложении. Часть 2