Вот вы пишете, что были на 25+ собеседованиях. А я - на 250+, и чуть меньше - сам проводил.
Это архитектурная статья, не совсем для разработчиков. Для ее прочтения нужно как минимум хорошо понимать такие буквы, как DRY, ACID, SOLID, CAP, API, TCP, SDK, MQ, REST, RPC, RESTFul, k8s, DDD, а еще владеть буржуйским языком, в котором: concurrency, api first, swagger, asyncapi, и много чего другого.
И статья в основном про глубокую степень контейнеризации элементов системы, сиречь jvm-стек в оркестрации.
И это я не упомянул массу других нюансов, как безопасность и инкапсуляция инфраструктуры и данных.
Толк будет, если всё это изучить. Таков беспощадный оскал современного облачного энтерпрайза.
3 А вот вынос DAO оправдался. За счёт Contract First сложная вложенность классов в DTO, почти 1-к-1 маппится на доменную модель, она тоже "структурированная", в одном из продуктов видно. На это опираются валидации и всякие пользовательские истории. А вот модели хранения упростили, "уплостили", в одном из продуктов навесили проекций.
Для будущей поддержки, поиска данных должно быть проще. Ну и часть искусственных требований нам выдвинули.
Но, к слову, там удалось модели сделать так, чтоб чуть оптимизировать хранение и поиск. Использовали особенности РСУБД. Еще один аргумент за слой persistence.
2 Разбиение домена на модели и логику насадили извне можно сказать. От этого вижу один сравнительно маленький плюс: слои чуть меньше, модели почти не меняются, меняется логика, оптимизация сборки градлом. Слабый аргумент. Думаю, через год может что-то измениться, когда получим опыт разработки и поддержки.
Доменные модели лично я запрещал с логикой. Дата-классы. В других командах мягче требования.
Дополнительную логику от дата-классов выносили в экстеншены (это в котлине типа утилитарных методов), отдельно, но при необходимости. Это обычно для логов, мониторинга, упрощение обращений к каким-то полям. Ничего длинного и сложного.
Набор слоёв частично пришёл "сверху", немного другой. Добавить получилось, убрать - нет. Громко ныл на собраниях, в будущем доменные слои может удастся склеить. Но будет уже много кода, и будет не так просто убирать.
1 Connector, messaging, persistence - имплементация портов, это про гексагональность. В будущем действительно может измениться тип СУБД. Остальные имплементации вряд ли. У меня тоже сомнения в уместности.
Что касается коннекторов. Обращения к общим, системным сервисам, постепенно выносится в корпоративную библиотеку, так что там скоро останутся импорты. Обращения к другим сервисам продукта сейчас пытаются кодогенерировать по контракту, так что, наверно, со временем количество кода в этом слое уменьшится.
Что касается messaging. Если условно приватные и публичные интеграции. Такие контракты утверждаются разными способами, чуть разные требования. Разделение на внешние и внутренние позволит лучше контролировать рзменения, и показывает разработчику, что можно шатать, а что - ни в коем случае.
Что касается app. Там интеграционные тесты и отдельный подсчет покрытия. Имхо получился сплав жёсткого насаждения и компетенций девопсеров. С продуктовой точки зрения наверно бесмыссленный слой, только приложение, стартующее всю спринговую машину.
Как руководитель... не факт, что нашли б общий язык или сработались.
Проекты разные - цели разные. Команды отличаются - ценности отличаются.
Сколько руководителей - столько же вариантов аджайла.
У нас на проекте изначально ставились высокие планки для кандидатов, во всех направлениях, на многих должностях/ролях. Некоторые лиды искали только сеньоров или даже выше. Некоторые проводили трёхчасовые тех. интервью. Зачем и почему - вопросы точно не ко мне.
И еще раз уточняю: каждая задача - это повод поговорить. Цель - не унизить человека, а найти.
А тут нечего считать, и сослагательное наклонение не нужно.
Проходил.
И задачи с таких интервью меня вдохновили. Тиньков, РТК, кажется Леруа или Ашан (французское что-то) и пару неизвестных контор. А остальные 500 своих собеседований я не запомнил.
Я работаю с этими людьми почти год. Готовлю статью о команде.
У меня вообще закралась мысль, что подобные интервью созданы специально, что бы бездари, которые пришли после 2 недельных курсов во время ковида не теряли места
Я не спорю, что вкатуны - проблема. Как попытались вкатиться - так и выкатывались, некоторые убегали с интервью до задач. Одна из моих задач было проверить понимание. Другая - выявить широту и глубину кругозора, об этом предыдущая статья.
а инженеры не могли найти нормальную работу.
Слишком наивное утверждение. Бизнес не будет тратить деньги, чтоб утвердить самомнение ноунеймов. Другое дело, что в отдельных продуктах задачи - это штамповки, и менее инженеры, более удобные и спокойные нужны.
И, да, во многих компаниях не умеют проводить интервью.
Да, действительно зачем в статье с названием про архитектуру писать что-то про архитектуру.
"Что-то" не хочу, я не индус и не Маяковский, нет KPI по строкам.
ADR и C4 неприменимы в этом контексте и на этом уровне абстракции, он слишком низко находится для таких аббревиатур. Употребление этих терминов потребовало бы совсем другую статью, другую целевую аудиторию и другие хабы. Нельзя в одной статье рассказывать и поо контекст контейнера, и про слои микросервиса. Было бы смешение уровней абстракций.
Насчет проброса ошибок. В принципе, от слоёв ddd отличий почти нет.
В "портовых" слоях ловим asap, оборачиваем в ошибку (которая exception или которая data class, в этом контексте не важно), ошибка через интерфейс- порт доходит до доменного слоя (тут не важно, склеены domain и domain-logic), дальше или возвращается в качестве ответа в web client, либо спринговый aop перехватывает и формирует ответ.
Если же доменная логика вызвана не из web-слоя, то по ошибке формируется event или response, смотря по какой схеме работаем с асинхронщиной.
Возможен гибридный подход, когда в условную кафку event всегда генерируется, независимо от успешности, и дальше в web возаращается.
Так что отвечая на ваш вопрос
будет с доменного слоя тянуться, а не со слоя с базой данных?
Да, доменное исключение с доменного слоя
И
эта ошибка
Нет, не "эта". Сама ошибка jpa инкапсулирована в своем слое хранения и не идет за границы, как, например, не идут dao-модели.
А вот на этот вопрос:
а если к базе не получится подключиться
ответ такой: это подключение в Java-spring-data происходит несколько раньше клиентского вызова, не в иомент обработки запроса. Условно говоря, его делают нагенерированные спрингом классы, стартующие с сервисом.
Да, тема важная, горячая, сложновата. Я давно варюст в таком энтерпрайзе, для меня это скорее средний уровень, но перестраховался и поставил сложный. Как оказалось - не зря. (Такое ощущение, что комментируют не читая).
Сам проект - увы. Для написания питомца тоже сложновато, нет столько времени. И для питомцев все это не нужно.
Но. Я тут уговариваю электронного товарища сварганить картинку - имитацию дерева проекта в идее. Добавлю в статью, лучше должно стать.
Вот вы пишете, что были на 25+ собеседованиях. А я - на 250+, и чуть меньше - сам проводил.
Это архитектурная статья, не совсем для разработчиков. Для ее прочтения нужно как минимум хорошо понимать такие буквы, как DRY, ACID, SOLID, CAP, API, TCP, SDK, MQ, REST, RPC, RESTFul, k8s, DDD, а еще владеть буржуйским языком, в котором: concurrency, api first, swagger, asyncapi, и много чего другого.
И статья в основном про глубокую степень контейнеризации элементов системы, сиречь jvm-стек в оркестрации.
И это я не упомянул массу других нюансов, как безопасность и инкапсуляция инфраструктуры и данных.
Толк будет, если всё это изучить. Таков беспощадный оскал современного облачного энтерпрайза.
Можно перейти по ссылкам в статье, почитать упомянутые книги, может появится толк.
Логика рядом, чем не DDD? Может не очень канонично.
Там вопрос еще расчета покрытия тестами. Интерфейсы и дата-классы не нуждаются. По маскам имен и путей проще исключать единообразно.
4 Юниты в каждом слое с кодом кроме app. Вроде писал. Рисовать не стал, чтоб не мусорить.
3 А вот вынос DAO оправдался. За счёт Contract First сложная вложенность классов в DTO, почти 1-к-1 маппится на доменную модель, она тоже "структурированная", в одном из продуктов видно. На это опираются валидации и всякие пользовательские истории. А вот модели хранения упростили, "уплостили", в одном из продуктов навесили проекций.
Для будущей поддержки, поиска данных должно быть проще. Ну и часть искусственных требований нам выдвинули.
Но, к слову, там удалось модели сделать так, чтоб чуть оптимизировать хранение и поиск. Использовали особенности РСУБД. Еще один аргумент за слой persistence.
2 Разбиение домена на модели и логику насадили извне можно сказать. От этого вижу один сравнительно маленький плюс: слои чуть меньше, модели почти не меняются, меняется логика, оптимизация сборки градлом. Слабый аргумент. Думаю, через год может что-то измениться, когда получим опыт разработки и поддержки.
Доменные модели лично я запрещал с логикой. Дата-классы. В других командах мягче требования.
Дополнительную логику от дата-классов выносили в экстеншены (это в котлине типа утилитарных методов), отдельно, но при необходимости. Это обычно для логов, мониторинга, упрощение обращений к каким-то полям. Ничего длинного и сложного.
Набор слоёв частично пришёл "сверху", немного другой. Добавить получилось, убрать - нет. Громко ныл на собраниях, в будущем доменные слои может удастся склеить. Но будет уже много кода, и будет не так просто убирать.
1 Connector, messaging, persistence - имплементация портов, это про гексагональность. В будущем действительно может измениться тип СУБД. Остальные имплементации вряд ли. У меня тоже сомнения в уместности.
Что касается коннекторов. Обращения к общим, системным сервисам, постепенно выносится в корпоративную библиотеку, так что там скоро останутся импорты. Обращения к другим сервисам продукта сейчас пытаются кодогенерировать по контракту, так что, наверно, со временем количество кода в этом слое уменьшится.
Что касается messaging. Если условно приватные и публичные интеграции. Такие контракты утверждаются разными способами, чуть разные требования. Разделение на внешние и внутренние позволит лучше контролировать рзменения, и показывает разработчику, что можно шатать, а что - ни в коем случае.
Что касается app. Там интеграционные тесты и отдельный подсчет покрытия. Имхо получился сплав жёсткого насаждения и компетенций девопсеров. С продуктовой точки зрения наверно бесмыссленный слой, только приложение, стартующее всю спринговую машину.
Да, разговоры с яндексом стабильно приводят к "рукалицо".
Они богатые, свои причуды. И люди же тянутся.
Не люблю вангование и игру в экстрасенсов.
Как руководитель... не факт, что нашли б общий язык или сработались.
Проекты разные - цели разные. Команды отличаются - ценности отличаются.
Сколько руководителей - столько же вариантов аджайла.
У нас на проекте изначально ставились высокие планки для кандидатов, во всех направлениях, на многих должностях/ролях. Некоторые лиды искали только сеньоров или даже выше. Некоторые проводили трёхчасовые тех. интервью. Зачем и почему - вопросы точно не ко мне.
И еще раз уточняю: каждая задача - это повод поговорить. Цель - не унизить человека, а найти.
А тут нечего считать, и сослагательное наклонение не нужно.
Проходил.
И задачи с таких интервью меня вдохновили. Тиньков, РТК, кажется Леруа или Ашан (французское что-то) и пару неизвестных контор. А остальные 500 своих собеседований я не запомнил.
А чему коллеги сопротивляются, если не NDA? И какие аргументы?
Быстро структуру проекта можно показать только так
Я работаю с этими людьми почти год. Готовлю статью о команде.
Я не спорю, что вкатуны - проблема. Как попытались вкатиться - так и выкатывались, некоторые убегали с интервью до задач. Одна из моих задач было проверить понимание. Другая - выявить широту и глубину кругозора, об этом предыдущая статья.
Слишком наивное утверждение. Бизнес не будет тратить деньги, чтоб утвердить самомнение ноунеймов. Другое дело, что в отдельных продуктах задачи - это штамповки, и менее инженеры, более удобные и спокойные нужны.
И, да, во многих компаниях не умеют проводить интервью.
Вы оцениваете людей, не видя их, без общения?
"Что-то" не хочу, я не индус и не Маяковский, нет KPI по строкам.
ADR и C4 неприменимы в этом контексте и на этом уровне абстракции, он слишком низко находится для таких аббревиатур. Употребление этих терминов потребовало бы совсем другую статью, другую целевую аудиторию и другие хабы. Нельзя в одной статье рассказывать и поо контекст контейнера, и про слои микросервиса. Было бы смешение уровней абстракций.
Отсылки к бест практис и книгам по ссылкам в статье. Если никогда не читать и не пользоваться - то никогда не узнать, верно.
По меткам и хабам должна быть отсылка к java.
Но стоит в тизере указать ещё раз, возможно.
Насчет проброса ошибок. В принципе, от слоёв ddd отличий почти нет.
В "портовых" слоях ловим asap, оборачиваем в ошибку (которая exception или которая data class, в этом контексте не важно), ошибка через интерфейс- порт доходит до доменного слоя (тут не важно, склеены domain и domain-logic), дальше или возвращается в качестве ответа в web client, либо спринговый aop перехватывает и формирует ответ.
Если же доменная логика вызвана не из web-слоя, то по ошибке формируется event или response, смотря по какой схеме работаем с асинхронщиной.
Возможен гибридный подход, когда в условную кафку event всегда генерируется, независимо от успешности, и дальше в web возаращается.
Так что отвечая на ваш вопрос
Да, доменное исключение с доменного слоя
И
Нет, не "эта". Сама ошибка jpa инкапсулирована в своем слое хранения и не идет за границы, как, например, не идут dao-модели.
А вот на этот вопрос:
ответ такой: это подключение в Java-spring-data происходит несколько раньше клиентского вызова, не в иомент обработки запроса. Условно говоря, его делают нагенерированные спрингом классы, стартующие с сервисом.
Да, вы говорите про слои ddd, как кажется, я тоже когда-то делал так или dto-api-impl(domain-dao-web).
Верно, работать надо)
Наверно со временем нейронкой по картинке сгенерирую прототип, чтоб подсунуть в статью в качестве примера.
Да, тема важная, горячая, сложновата. Я давно варюст в таком энтерпрайзе, для меня это скорее средний уровень, но перестраховался и поставил сложный. Как оказалось - не зря. (Такое ощущение, что комментируют не читая).
Сам проект - увы. Для написания питомца тоже сложновато, нет столько времени. И для питомцев все это не нужно.
Но. Я тут уговариваю электронного товарища сварганить картинку - имитацию дерева проекта в идее. Добавлю в статью, лучше должно стать.
Обязательно отвалится! Как и брокер, и редис с сентиэлями. Но, как правило, это не в рамках бизнес сценариев. И зачастую не в тех потоках.
В идеале мониторщики с елк или Prometeus-Tempo-Loki-Grafana помогают.