потому что идея адаптеров пришла из статьи про "порты адаптеры", где они так определяются. Если использовать для входа одно название, а для выхода другое, то это уже не так, как написано в статье. Из чего получаем n+1 интерпретацию, где n уже около миллиона.
В целом проблемы нет, можно называть как душе угодно и оно возможно даже будет компилироваться, но это не то, что можно загуглить и прочитать где-то и не то, что в оригинале называется "порты адаптеры".
Нет слоя портов. Порты - это интерфейсы, а они должны лежать там же, где и потребители этих интерфейсов то есть в слое application.
В инфраструктуре часть адаптеров лежит в папке адаптерс, а часть вне ее...
Первая картинка - вообще я считаю шедевр:
Нарисована в пеинте
Не правила зависимостей, а правило зависимостей - оно одно
Домен зависит от инфры...
ДДД вообще к этому не имеет отношения
В общем, я очень за изучение этой темы кем бы то ни было, но я не понимаю, зачем писать статью, если нет понимания. Сколько статей или репозиториев про чистую архитектуру и ддд не встречаешь - везде какие-то элементарные ошибки. Еще ладно в каких-то сложных вещах, но обычно в самых простых, вроде базового правила зависимостей.
И это порочный круг, изучают тему по статьям, а потом пишут свои. Сломанный телефон в итоге все приходят к мнению, что чистая архитектура - это сложно и переусложнение. Не удивительно - по всей той каше, что в статьях неясно, как разобраться можно.
Неправильно. Хватит демонизировать джаву. Го не создавали, чтобы он был НЕ КАК джава. Го скорее создавали для других типов задач, вроде инфраструктуры, где он себя кстати отлично чувствует (докер, кубер).
Но на го начали писать энтерпрайз приложения, а они обладают большой сложностю, которая продиктованна сложностью предметной области. И чтобы с этой сложностью совладать можно использовать разные паттерны, которые до этого использовались в джаве, как раз с целью совладания со сложностью!
Более абсурдным выглядит писать энтерпрайз приложения, где много бизнес логики и не использовать ничего из этого. В этом случае вы столкнетесь лицом к лицу с этой сложностью. Ее можно конечно отрицать и это почему-то популярно, но всё же приятнее, когда все упорядочено и не надо всё держать в голове.
А на файлы разделять за тем же, за чем и просто что-то большое разбивать на что-то мелкое - декомпозиция сложности. Все паттерны, все солиды, все эти DRY, KISS, GRASP и т.д. про совладание со сложностью.
ну, если стажеры убегут с такими мыслями, значит будет тот работодатель, у которого они получат эти деньги. Верно ведь? Вряд ли же они убегут в никуда т.к. считают, что недостойны получать 60-65.
Отсюда вопрос, почему бы работодателю, который этих стажеров первым принял не увеличить их зп, чтобы они не бежали. Не бежать при прочих равных (зп) гораздо проще, чем бежать.
Аналогия — не способ доказательства.
Причем в вашей аналогии сразу много нестыковок. И если ей следовать, то мы не должны давать задачи сеньерам, а джунам должны, то выходит опытным преподавателям мы не должны давать провести урок по теории чисел, а тем, кто сразу после вуза должны?)
Если вы во время джунства не научились решать простейшие задачки, то как тот факт, что по прошествии n лет вы, уже называя себя сеньером, можете решать такие задачки?
Ну может вы и можете сделать там импорт..., но неумение решать задачки покажет, что вы скорее всего их никогда и не решали и не прошли этот этап и не обладаете, как и не обладали способностью мыслить подобным образом. Это просто ваша лень. имхо
Томас Кормен - Алгоритмы. Вводный курс максимально бы не советовал эту. Она сложная. Об этом говорят и комментарии на амазоне\quora и самому мне так показалось.
Есть великолепная книга про алгоритмы для новичков, но к сожалению только на англ:
Автор пишет, что она oversimplified, но она правда крута. Также у автора где-то есть статья про то, как проводить алгособесы, всем советую найти и почитать :)
Слушал этот курс. Не спорю, что вещи говорятся верные, но мне кажется, что хорошим он будет казаться только, если сети уже понимаешь. Я слушал, когда не знал сети и особо пользы не нашел.
Таненбаума джунам тем более нельзя читать для базового понимания)
Мне сложно тут говорить, ибо сам в поисках, но пока, есть подозрения, что будут лучше:
2.1 Книга Олиферов по сетям (не та, которая большая, как Таненбаум, а короткая в 300 стр).
Я понимаю, любовь к Таненбауму, и, что это классика, и, что во всех университетах она в списке рекомендованной литературы скорее всего, но блин - это Таннебаум. Я к своему горю прочитал его сети и архитектуру, сейчас же считаю, что лучше бы прочитал вместо каждой по две более легкие книги, а в эти бы заглядывал, как в справочник.
По операционкам есть просто великолепная (опять же без перевода на русский):
Я понимаю, что мои "советы" не будут супер полезны, т.к. про сети я толком сам не знаю, что есть хорошего, но просто против советов о Таненбауме, а остальные две книги только на английском, но надеюсь кому-то всё же пригодится.
Как инженерная задача — интересно.
А готовые сервисы не подходят?
Кстати, подумайте о таком моменте. Как бы не просто так у нас у всех в телефонах фотографии хранятся в виде структуры — лента. По сути, ваша иерархия и есть лента т.к. она отсортирована по годам.
В вашем случае папки нужны для того, чтобы вам, как человеку, было легче найти нужный файл по дате, но именно для задачи хранения они не необходимы. То есть функция, которую они выполняют должна скорее относиться к «интерфейсу», а не системе хранения. В гугл фото, например, нет папок т.к. интерфейс берет на себя функцию, помогающую человеку найти фото быстро.
Я очень рад, что однажды пересилил себя и перешел на гугл фотос. И сейчас понимаю, что те причины, которые останавливали тогда — это скорее мозг противился чему-то новому. Сейчас мне концепция очень нравится. Жаль только сервис перейдет на платную основу в скором времени.
потому что идея адаптеров пришла из статьи про "порты адаптеры", где они так определяются. Если использовать для входа одно название, а для выхода другое, то это уже не так, как написано в статье. Из чего получаем n+1 интерпретацию, где n уже около миллиона.
В целом проблемы нет, можно называть как душе угодно и оно возможно даже будет компилироваться, но это не то, что можно загуглить и прочитать где-то и не то, что в оригинале называется "порты адаптеры".
какая-то каша. Порты driven/driving, а адаптеры primary/secondary - зачем по-разному называть? Неясно.
Нет слоя портов. Порты - это интерфейсы, а они должны лежать там же, где и потребители этих интерфейсов то есть в слое application.
В инфраструктуре часть адаптеров лежит в папке адаптерс, а часть вне ее...
Первая картинка - вообще я считаю шедевр:
Нарисована в пеинте
Не правила зависимостей, а правило зависимостей - оно одно
Домен зависит от инфры...
ДДД вообще к этому не имеет отношения
В общем, я очень за изучение этой темы кем бы то ни было, но я не понимаю, зачем писать статью, если нет понимания. Сколько статей или репозиториев про чистую архитектуру и ддд не встречаешь - везде какие-то элементарные ошибки. Еще ладно в каких-то сложных вещах, но обычно в самых простых, вроде базового правила зависимостей.
И это порочный круг, изучают тему по статьям, а потом пишут свои. Сломанный телефон в итоге все приходят к мнению, что чистая архитектура - это сложно и переусложнение. Не удивительно - по всей той каше, что в статьях неясно, как разобраться можно.
оптимизацией чего? Если будет 10 млн списков дел и в каждом спике по 1-2 делу, а всего в нескольких по 10, то это не оптимизация.
Без паттерна использования и измерений не надо ничего оптимизировать, а то как раз "преждевременная" и получится
Отличная статья, спасибо. Статей на эти темы много, но зачастую они бестолковые и с уймой ошибок. Тут же видно, что автор изучал то, о чем пишет.
Неправильно. Хватит демонизировать джаву. Го не создавали, чтобы он был НЕ КАК джава. Го скорее создавали для других типов задач, вроде инфраструктуры, где он себя кстати отлично чувствует (докер, кубер).
Но на го начали писать энтерпрайз приложения, а они обладают большой сложностю, которая продиктованна сложностью предметной области. И чтобы с этой сложностью совладать можно использовать разные паттерны, которые до этого использовались в джаве, как раз с целью совладания со сложностью!
Более абсурдным выглядит писать энтерпрайз приложения, где много бизнес логики и не использовать ничего из этого. В этом случае вы столкнетесь лицом к лицу с этой сложностью. Ее можно конечно отрицать и это почему-то популярно, но всё же приятнее, когда все упорядочено и не надо всё держать в голове.
А на файлы разделять за тем же, за чем и просто что-то большое разбивать на что-то мелкое - декомпозиция сложности. Все паттерны, все солиды, все эти DRY, KISS, GRASP и т.д. про совладание со сложностью.
ну, если стажеры убегут с такими мыслями, значит будет тот работодатель, у которого они получат эти деньги. Верно ведь? Вряд ли же они убегут в никуда т.к. считают, что недостойны получать 60-65.
Отсюда вопрос, почему бы работодателю, который этих стажеров первым принял не увеличить их зп, чтобы они не бежали. Не бежать при прочих равных (зп) гораздо проще, чем бежать.
Причем в вашей аналогии сразу много нестыковок. И если ей следовать, то мы не должны давать задачи сеньерам, а джунам должны, то выходит опытным преподавателям мы не должны давать провести урок по теории чисел, а тем, кто сразу после вуза должны?)
Если вы во время джунства не научились решать простейшие задачки, то как тот факт, что по прошествии n лет вы, уже называя себя сеньером, можете решать такие задачки?
Ну может вы и можете сделать там импорт..., но неумение решать задачки покажет, что вы скорее всего их никогда и не решали и не прошли этот этап и не обладаете, как и не обладали способностью мыслить подобным образом. Это просто ваша лень. имхо
Далее:
Удобно писать конкуррентный код
Статический бинарник (cloud friendly)
Единый формат кода благодаря утилите gofmt. Поэтому код на го всегда одинаковый. Сюда же простой синтаксис.
Удобная экосистема. Тестирование\бенчмарки\профайлинг из коробки
и т.д.
Хотел написать про книги.
1.
Томас Кормен - Алгоритмы. Вводный курс максимально бы не советовал эту. Она сложная. Об этом говорят и комментарии на амазоне\quora и самому мне так показалось.
Есть великолепная книга про алгоритмы для новичков, но к сожалению только на англ:
A Common-Sense Guide to Data Structures and Algorithms ( https://www.amazon.com/Common-Sense-Guide-Structures-Algorithms-Second/dp/1680507222 ).
Автор пишет, что она oversimplified, но она правда крута. Также у автора где-то есть статья про то, как проводить алгособесы, всем советую найти и почитать :)
2.
Андрей Созыкин - Компьютерные сети. Базовый курс
Слушал этот курс. Не спорю, что вещи говорятся верные, но мне кажется, что хорошим он будет казаться только, если сети уже понимаешь. Я слушал, когда не знал сети и особо пользы не нашел.
Таненбаума джунам тем более нельзя читать для базового понимания)
Мне сложно тут говорить, ибо сам в поисках, но пока, есть подозрения, что будут лучше:
2.1 Книга Олиферов по сетям (не та, которая большая, как Таненбаум, а короткая в 300 стр).
2.2. Курс ссна
3.
Эндрю Таненбаум - Современные операционные системы
Я понимаю, любовь к Таненбауму, и, что это классика, и, что во всех университетах она в списке рекомендованной литературы скорее всего, но блин - это Таннебаум. Я к своему горю прочитал его сети и архитектуру, сейчас же считаю, что лучше бы прочитал вместо каждой по две более легкие книги, а в эти бы заглядывал, как в справочник.
По операционкам есть просто великолепная (опять же без перевода на русский):
Operating Systems: Three Easy Pieces ( https://pages.cs.wisc.edu/~remzi/OSTEP/ ) - ее читать было сплошным удовольствием.
Я понимаю, что мои "советы" не будут супер полезны, т.к. про сети я толком сам не знаю, что есть хорошего, но просто против советов о Таненбауме, а остальные две книги только на английском, но надеюсь кому-то всё же пригодится.
Web Scalability for Startup Engineers
А готовые сервисы не подходят?
Кстати, подумайте о таком моменте. Как бы не просто так у нас у всех в телефонах фотографии хранятся в виде структуры — лента. По сути, ваша иерархия и есть лента т.к. она отсортирована по годам.
В вашем случае папки нужны для того, чтобы вам, как человеку, было легче найти нужный файл по дате, но именно для задачи хранения они не необходимы. То есть функция, которую они выполняют должна скорее относиться к «интерфейсу», а не системе хранения. В гугл фото, например, нет папок т.к. интерфейс берет на себя функцию, помогающую человеку найти фото быстро.
Я очень рад, что однажды пересилил себя и перешел на гугл фотос. И сейчас понимаю, что те причины, которые останавливали тогда — это скорее мозг противился чему-то новому. Сейчас мне концепция очень нравится. Жаль только сервис перейдет на платную основу в скором времени.
Но действительно, главное не назвать свой недостаток, а показать, как ты превратил его в преимущество.