"Где-то" LLM действительно может штамповать сервисы, а у нас конкретно - куча НФТ, так что без локальной/корпоративной LLM с хорошими ресурсами не обойтись. В любом случае это вопрос, может и недалёкого, но будущего.
ИИ - вообще отдельная тема. Сейчас провожу эксперимент, начал писать статью. Пока скептически отношусь. Может, удастся сделать полезные выводы. Многое, понятное дело, упирается в ресурсы.
На текущий момент мы не можем полностью автоматизировать. Проекты в каком-то необычном гибридном состоянии. Мы с коллегами пытаемся заранее чуть "подстелить соломки". Я в прошлом году, например, отфильтровывал с рынка сильных профессионалов, о чем писал статьи,- даже при наличии материальных ресурсов кому-то надо отслеживать и валидировать результаты, когда внезапно накроет светлым будущим.
Пока что работаем через высокую планку входа и попытки формализации архитектурных нюансов. Время покажет, насколько оправдано. Имхо, результат, каким бы то ни был, покажется в ближайший год.
Лига цифровой экономики например, на федеральных проектах. Лет 7 назад уже использовали. Не на что, так не на что. Компания с 5000 сотрудников может ошибаться, именно поэтому развиваются и растут.
Нет, цитата о половине пустых слоев не от меня. И у меня в продуктовом коде не так. У каждого слоя свое предназначение, разделение по зоне ответственности даже для людей : что-то правит разработчик, что-то аналитик.
И не пытался учить, нет таких целей. Я рассказываю, как делают у меня на проекте. Кто не понимает подходов - волен реализовывать все в одном методе.
Нет, не три слоя.
В openapi наборы ямлов от аналитиков и архитекторов, каждый может отвечать за свою часть, дальше арх. надзор , аппрув и компиляция в общий openapi, по которому отрабатывает openapi-generator. Это полноценный слой, в котором работают только аналитики и архитекторы. Код там ямлы, который они собирают. В этом же слое, при необходимости, можно настроить генерацию схемы для документации.
В asyncapi ямл и dto. В зависимости от микросервиса и особенностей стека эти dto contract first или написаны разработчиком. Могут быть вспомогательные классы при необходимости. Цель слоя-публикация артефакта в нексус и фиксация контракта. Возможна гибкость. При наличии доп. кода юнит-тесты, обычно нет или мало.
Api - слой со сгенерированными классами для обмена, тоже могут быть вспомогательные классы, тоже нужно для публикации.
Как тут вообще люди считают? То половина пустых слоев, то три.
Да, местами сложность уходит в бюрократию, потом в легаси, а потом в заморозку релизов.
Насчет того, что архитектура прям-таки уходит в большую простоту - не могу согласиться: по-разному бывает. В разных компаниях и на разных стеках я видел диаметрально противоположные подходы буквально ко всему. И везде были аргументы.
Когда-то я в противовес этой хореографии и слоям реализовывал SOA без оркестратора и брокера, на шине. Ещё раньше - серверную часть на БД. И трёхслойку по библии Эванса делал. И двухязычный монолит. Архитектур - море. Как фломастеров.
Есть здравые мысли. Американцы, вообще-то, продвигают такие подходы. Тот же г-н Эванс.
Для менее квалифицированного русского коммюнити такие подходы, пожалуй, сложноваты. Я писал похожий архитектурный разбор реальных проектов, заминусили и отписались:
Я не понимаю ничего в DDD, зачем вы столько воды льете, толку ноль.
Вообще слоистость +- в таком виде уже больше 7 лет работает в энтерпрайзе в разных компаниях.
Но, блин, у вас минимум в двух курсах аналитик, тестировщик и автор статьи не общаются друг с другом, видны дыры между теорией, практикой и автотестами. Заставьте этих людей поговорить, у вас же телемост даже есть. Новичкам такое несоответствие взрывает мозги, они бросают курсы. Деньги-то вы все равно получите, но люди получают фикцию, не надо так.
А вот эмуляция аджайла зачётная. Только группы стажёров у вас не самоорганизуются, надо управлять процессами, назначив кого-то из своих лидом или ПО, называйте как хотите.
Вот вы пишете, что были на 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 Да, но тут тонкие политические моменты. Их документации изучались аналитиками неск. лет назад.
2 Да, может и так, но тут как говорится, "всё решено до нас".
"Где-то" LLM действительно может штамповать сервисы, а у нас конкретно - куча НФТ, так что без локальной/корпоративной LLM с хорошими ресурсами не обойтись. В любом случае это вопрос, может и недалёкого, но будущего.
ИИ - вообще отдельная тема. Сейчас провожу эксперимент, начал писать статью. Пока скептически отношусь. Может, удастся сделать полезные выводы. Многое, понятное дело, упирается в ресурсы.
На текущий момент мы не можем полностью автоматизировать. Проекты в каком-то необычном гибридном состоянии. Мы с коллегами пытаемся заранее чуть "подстелить соломки". Я в прошлом году, например, отфильтровывал с рынка сильных профессионалов, о чем писал статьи,- даже при наличии материальных ресурсов кому-то надо отслеживать и валидировать результаты, когда внезапно накроет светлым будущим.
Пока что работаем через высокую планку входа и попытки формализации архитектурных нюансов. Время покажет, насколько оправдано. Имхо, результат, каким бы то ни был, покажется в ближайший год.
Лига цифровой экономики например, на федеральных проектах. Лет 7 назад уже использовали. Не на что, так не на что. Компания с 5000 сотрудников может ошибаться, именно поэтому развиваются и растут.
Я же названия конкретные писал. Названия выдуманные? Серьёзно? Можно устроиться на работу, если возьмут, посмотреть всё изнутри.
Нет, цитата о половине пустых слоев не от меня. И у меня в продуктовом коде не так. У каждого слоя свое предназначение, разделение по зоне ответственности даже для людей : что-то правит разработчик, что-то аналитик.
Код может и да. Но ошибки аналитики, проектирования, контрактов.
И не пытался учить, нет таких целей. Я рассказываю, как делают у меня на проекте. Кто не понимает подходов - волен реализовывать все в одном методе.
Нет, не три слоя.
В openapi наборы ямлов от аналитиков и архитекторов, каждый может отвечать за свою часть, дальше арх. надзор , аппрув и компиляция в общий openapi, по которому отрабатывает openapi-generator. Это полноценный слой, в котором работают только аналитики и архитекторы. Код там ямлы, который они собирают. В этом же слое, при необходимости, можно настроить генерацию схемы для документации.
В asyncapi ямл и dto. В зависимости от микросервиса и особенностей стека эти dto contract first или написаны разработчиком. Могут быть вспомогательные классы при необходимости. Цель слоя-публикация артефакта в нексус и фиксация контракта. Возможна гибкость. При наличии доп. кода юнит-тесты, обычно нет или мало.
Api - слой со сгенерированными классами для обмена, тоже могут быть вспомогательные классы, тоже нужно для публикации.
Как тут вообще люди считают? То половина пустых слоев, то три.
Да, так и есть. Сейчас вот уже второй год пробуем работать по книгам о чистоте.
Да, местами сложность уходит в бюрократию, потом в легаси, а потом в заморозку релизов.
Насчет того, что архитектура прям-таки уходит в большую простоту - не могу согласиться: по-разному бывает. В разных компаниях и на разных стеках я видел диаметрально противоположные подходы буквально ко всему. И везде были аргументы.
Когда-то я в противовес этой хореографии и слоям реализовывал SOA без оркестратора и брокера, на шине. Ещё раньше - серверную часть на БД. И трёхслойку по библии Эванса делал. И двухязычный монолит. Архитектур - море. Как фломастеров.
Да, это NDA и свои гитлабы. Разве не так делают крупные компании?
Лига цифровой экономики, например. Некоторые проекты зелёного банка. Мой холдинг использует.
У нас разве холдинги публикуют в публичные репозитории исходный код сервисов?
А какие именно публикации? Есть литература, в основном англоязычная, можно посмотреть на медиуме, реддите, и даже на хабре.
Нужно подтверждение, что в амазоне и ibm используют такие подходы? Я без понятия, не читал их публикации последнее время.
Есть здравые мысли. Американцы, вообще-то, продвигают такие подходы. Тот же г-н Эванс.
Для менее квалифицированного русского коммюнити такие подходы, пожалуй, сложноваты. Я писал похожий архитектурный разбор реальных проектов, заминусили и отписались:
Вообще слоистость +- в таком виде уже больше 7 лет работает в энтерпрайзе в разных компаниях.
О, у вас такая же статья для решётки.
Не знал, насколько onion популярен в других ЯП.
В предыдущих коммантариях отвечал. Если кратко - это решение "сверху".
Постарались получить плюсы от такого подхода.
Вроде в кризис джунов вещь хорошая.
Но, блин, у вас минимум в двух курсах аналитик, тестировщик и автор статьи не общаются друг с другом, видны дыры между теорией, практикой и автотестами. Заставьте этих людей поговорить, у вас же телемост даже есть. Новичкам такое несоответствие взрывает мозги, они бросают курсы. Деньги-то вы все равно получите, но люди получают фикцию, не надо так.
А вот эмуляция аджайла зачётная. Только группы стажёров у вас не самоорганизуются, надо управлять процессами, назначив кого-то из своих лидом или ПО, называйте как хотите.
Вот вы пишете, что были на 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 Разбиение домена на модели и логику насадили извне можно сказать. От этого вижу один сравнительно маленький плюс: слои чуть меньше, модели почти не меняются, меняется логика, оптимизация сборки градлом. Слабый аргумент. Думаю, через год может что-то измениться, когда получим опыт разработки и поддержки.
Доменные модели лично я запрещал с логикой. Дата-классы. В других командах мягче требования.
Дополнительную логику от дата-классов выносили в экстеншены (это в котлине типа утилитарных методов), отдельно, но при необходимости. Это обычно для логов, мониторинга, упрощение обращений к каким-то полям. Ничего длинного и сложного.