Спасибо за видео! Да, формат с live drawing крут! Единственное, хотелось бы стрелки либо рисовать толще или другим цветом, чтобы были заметнее. Еще интересны два вопроса: 1. как вы продаете Clean Arch разработчикам? Особенно, которые привыкли "вращать деревья", а не вот это "ваше все" 2. Как вы продаете Clean Arch бизнесу? Разработка в парадигме занимает много времени на старте, но зато быстрее вносить изменения. Но вот именно долгий старт приходится продавать
Спасибо большое за обратную связь. Правда, очень приятно читать. Я наверное запилю отдельное видео, но не могу обещать что будет скоро. Поэтому отвечу и здесь. Для начала про бизнес. Я за подход, когда "разработчики проффесионалы и сами решат какие применять средства". То есть бизнесу не особо и надо знать пишем ли мы тесты, какую архитектуру или фреймворк использует. Понятно что бизнес лезет со своими рекомендациями когда разрабам тесты писать и какую архитектуру использовать. Но на мой взгляд надо дать понять, что существуют разделения обязанностей. Ну и если доверия с бизнесом уже есть, то он даже и спрашивать не будет. С разрабами сложнее. Особенно с теми, кто "деревья крутить" привык. Если вы тимлид и проект новый, то проще всего "ночью" напилить скелет проекта с clear architecture, навставлять туда линтеров, чтобы не сломали и сказать "ну все, эта архитектура дана нам свыше, обсуждение закончено" Если проект уже идет -- тут придется искать поддержку у разрабов. ЛУчший путь на мой взгляд обучение (пошарить Поваренную книгу дядюшки боба) и поиск сочувствующих, то есть у кого есть такая же боль как и у вас. И если большинство разрабов посмотрели курс и согласились что вроде как по старому жить уже никакой мочи нет, то можно затевать рефакторинг. Если сопротивляются и держаться за свою горячо любимую слоеную архитектуру можно сказать "хорошо, пусть слоенка, но давайте раз и навсегда выясним куда будут направлены зависимости (внутрь бизнеса), давайте разделим слой инфрастуктуры на DataAccess layer и на интеграцию вон с той и другой системой". И вот незаметно проект может начинать hexagonal, хотя вы ниразу не произнесли это слово :)
Плагин - это отдельная сборка ? Тогда все зависимости собираем в корневом приложении , например , используя DI контейнер ? И если требуется подключить другой плагин, то решаем это изменением ссылки из корневого проекта ?
В терминах JVM, плагин -- это как минимум maven\gradle submodule. В других экосистемах по-другому. Но не обязательно что плагин живет прямо совсем отдельно, скажем в отдельном репозитории. И да, если нужно поменять реализацию, топ меняем ее в корневом приложении
ох, самому хочется сделать. Но тут знаете какая проблема: DDD начинается с бизнес-контекстов, с того чтобы работать с экспертами предметной области, и выражать это знание в коде. А тут посмотришь в код, а там процедурщина на 500 строк. И я прямо не знаю как сделать мостик от одного к другому :) Вы бы кстати, с чего начали?
@@stringconcatмаловато у меня опыта, но да, нужен список терминов и бизнесс понятий. Потом выявление баундед-контекстов и агрегатов/сущностей/value Object. Но не имея эксперта в домене, это все усложняется.
Слоеная - размыты границы и не знаешь, что куда пихать. Чистая - все правила четко прописаны. А вообще это подробно описано в 3х видеороликах данного канала
К сожалению в высоконагруженном бекенде все эти красивые архитектуры не очень работают. Точнее работает все, что не вызывает дополнительный оверхед на цпу и память. По факту остается только принцип инверсии зависимостей, а в остальном чем "ближе" нагруженный хендлер к данным, тем лучше.
Если у приложения требования "произовительность -- любой ценой". То есть, все остальные не функциональные характеристики сознательно приносятся в жертву производительности, то конечно clean architecture не подходит. Но для большинства приложений, которые мы с вами пишем производительность -- не краеугольный камень, и другие CFRs должны браться в расчет. И то, у типичного приложения можно выделить буквально пару workflow критичных к производительности, которые покрываются СQRS, а для остальных 90 можно использовать и CA
@@StormB87 Все просто. Когда нагрузка на сервис, скажем, 200к запросов в секунду, то выдержать ее можно либо раздувая количество подов в кубере, либо выжимая все соки из кода. А поскольку оборудование стоит денег, то всегда выбирается второе. И да, для всех приложений, которые я пишу производительность как раз и есть краиугольный камень. Ну и еще покрытие тестами, т.к. простой в минуту по потерям будет поболее годовой зарплаты всего отдела.
Жду продолжения!
Уже монтирую ;)
Классное видео!) респект, Сергей!)
Спасибо, Рафаэль!
Очень приятное и понятное освещение темы.
Спасибо!
Огонь!
Спасибо!
Спасибо, материал огонь!
Спасибо за видео! Да, формат с live drawing крут! Единственное, хотелось бы стрелки либо рисовать толще или другим цветом, чтобы были заметнее. Еще интересны два вопроса:
1. как вы продаете Clean Arch разработчикам? Особенно, которые привыкли "вращать деревья", а не вот это "ваше все"
2. Как вы продаете Clean Arch бизнесу? Разработка в парадигме занимает много времени на старте, но зато быстрее вносить изменения. Но вот именно долгий старт приходится продавать
Спасибо большое за обратную связь. Правда, очень приятно читать. Я наверное запилю отдельное видео, но не могу обещать что будет скоро. Поэтому отвечу и здесь.
Для начала про бизнес. Я за подход, когда "разработчики проффесионалы и сами решат какие применять средства". То есть бизнесу не особо и надо знать пишем ли мы тесты, какую архитектуру или фреймворк использует. Понятно что бизнес лезет со своими рекомендациями когда разрабам тесты писать и какую архитектуру использовать. Но на мой взгляд надо дать понять, что существуют разделения обязанностей. Ну и если доверия с бизнесом уже есть, то он даже и спрашивать не будет.
С разрабами сложнее. Особенно с теми, кто "деревья крутить" привык. Если вы тимлид и проект новый, то проще всего "ночью" напилить скелет проекта с clear architecture, навставлять туда линтеров, чтобы не сломали и сказать "ну все, эта архитектура дана нам свыше, обсуждение закончено"
Если проект уже идет -- тут придется искать поддержку у разрабов. ЛУчший путь на мой взгляд обучение (пошарить Поваренную книгу дядюшки боба) и поиск сочувствующих, то есть у кого есть такая же боль как и у вас. И если большинство разрабов посмотрели курс и согласились что вроде как по старому жить уже никакой мочи нет, то можно затевать рефакторинг.
Если сопротивляются и держаться за свою горячо любимую слоеную архитектуру можно сказать "хорошо, пусть слоенка, но давайте раз и навсегда выясним куда будут направлены зависимости (внутрь бизнеса), давайте разделим слой инфрастуктуры на DataAccess layer и на интеграцию вон с той и другой системой". И вот незаметно проект может начинать hexagonal, хотя вы ниразу не произнесли это слово :)
Огромное спасибо за развернутый ответ!
Плагин - это отдельная сборка ? Тогда все зависимости собираем в корневом приложении , например , используя DI контейнер ? И если требуется подключить другой плагин, то решаем это изменением ссылки из корневого проекта ?
В терминах JVM, плагин -- это как минимум maven\gradle submodule. В других экосистемах по-другому. Но не обязательно что плагин живет прямо совсем отдельно, скажем в отдельном репозитории.
И да, если нужно поменять реализацию, топ меняем ее в корневом приложении
Clean architecture - one love. Правда на работе не особо могу использовать, там целый зверинец подходов.
Быстро и доходчиво!
Спасибо!
И неправильно )
к лешему IoC - даёшь dependency rejection
Свободу Монадам, долой засилие процедурщины!
Partial Function каждому разработчику к 2035 году!
@@stringconcatмонады ортогональны IoC
Жду рассказ про DDD :)
ох, самому хочется сделать. Но тут знаете какая проблема: DDD начинается с бизнес-контекстов, с того чтобы работать с экспертами предметной области, и выражать это знание в коде. А тут посмотришь в код, а там процедурщина на 500 строк. И я прямо не знаю как сделать мостик от одного к другому :)
Вы бы кстати, с чего начали?
@@stringconcatмаловато у меня опыта, но да, нужен список терминов и бизнесс понятий. Потом выявление баундед-контекстов и агрегатов/сущностей/value Object. Но не имея эксперта в домене, это все усложняется.
Чем слоеная архитектура отличается от чистой ?
Слоеная - размыты границы и не знаешь, что куда пихать.
Чистая - все правила четко прописаны.
А вообще это подробно описано в 3х видеороликах данного канала
Направлением импортов, в чистой он противоположный.
Почему-то бот не работает.
Спасибо что сказали. Мы робота починили, теперь он не отлынивает ;)
К сожалению в высоконагруженном бекенде все эти красивые архитектуры не очень работают. Точнее работает все, что не вызывает дополнительный оверхед на цпу и память. По факту остается только принцип инверсии зависимостей, а в остальном чем "ближе" нагруженный хендлер к данным, тем лучше.
Если у приложения требования "произовительность -- любой ценой". То есть, все остальные не функциональные характеристики сознательно приносятся в жертву производительности, то конечно clean architecture не подходит.
Но для большинства приложений, которые мы с вами пишем производительность -- не краеугольный камень, и другие CFRs должны браться в расчет. И то, у типичного приложения можно выделить буквально пару workflow критичных к производительности, которые покрываются СQRS, а для остальных 90 можно использовать и CA
@@StormB87 Все просто. Когда нагрузка на сервис, скажем, 200к запросов в секунду, то выдержать ее можно либо раздувая количество подов в кубере, либо выжимая все соки из кода. А поскольку оборудование стоит денег, то всегда выбирается второе. И да, для всех приложений, которые я пишу производительность как раз и есть краиугольный камень. Ну и еще покрытие тестами, т.к. простой в минуту по потерям будет поболее годовой зарплаты всего отдела.
@@АлексейКиреев-н7на смысл считать простой в зарплатах отдела, если каждый работяга получает мизер от реальной стоимости своей работы
00:15 clean architecture и что еще?
Гексагонал.
Привет