Добро пожаловать во второй пост серии о Flowable Async Executor. В первой части мы рассмотрели базовые понятия: что такое асинхронные задания и таймеры, и почему они полезны при построении BPMN- и CMMN-моделей. В последнем разделе мы также показали общую схему новой архитектуры Async Executor.
Бывает, что в команде начинает что-то идти не так: увеличивается количество факапов, разработчики начинают увольняться, задачи делаются месяцами годами. Часть этих проблем может уходить корнями в накопленный техдолг.
В этой статье я хочу поделиться опытом организации работы по устранению техдолга в нескольких командах, в которых я побывал за 7 лет своей работы в Контуре. Продукты были разные: от стартапа и бурно развивающегося гиганта, до сервиса, переживающего не лучшие времена.
Каждый раз приходя в новую команду, я находился в растерянности и не понимал, за что бы взяться, чтобы начать менять удручающую ситуацию с техдолгом. Поэтому я решил собрать свои подходы в понятный план действий, который, конечно же, неидеален, но точно поможет вам начать работать с проблемами.
Внедрение атрибутивной модели доступа (ABAC) в крупной корпоративной системе на микросервисах — это всегда испытание для архитекторов, разработчиков и бизнес-аналитиков. ABAC — одна из самых сложных областей IAM (Identity and Access Management) в корпоративных платформах, и даже простая модель может сломать мозг и пользователям, и инженерам. Рассказываю, как я реализовал масштабируемую систему с миллионами сущностей без потери производительности и сохранили простоту API для конечного разработчика.
Все мы стремимся создавать более качественное программное обеспечение и делать это быстрее. Я считаю, что разработка через тестирование предлагает нам путь к этой цели. Все еще боитесь использовать этот подход? Тогда я приглашаю вас обсудить советы и приемы помогающие раскрыть преимущества TDD!
Что отличает архитектора от кодера? Не должность, не титул, не стаж.
Ответ - в мышлении. В том, кто видит систему целиком, предвидит цепные последствия и способен сказать "нет" быстрому решению, которое отравит код через полгода. Эта статья - честное и местами болезненное размышление о системном мышлении, архитектуре и точке невозврата, после которой разработчик уже не может смотреть на код по-старому.
Недавно наша команда столкнулась с новым проектом — крупной backend-системой, которую руководство решило реализовать в формате монорепозитория. Масштаб бизнес-логики оказался огромным, и быстро стало понятно, что без четкой архитектурной дисциплины невозможно поддерживать читаемость, изолировать бизнес-логику и эффективно управлять сложностью. Поэтому мы выбрали подход Domain-Driven Design (DDD), при котором домен описывает бизнес-правила, а оркестратор и инфраструктура вынесены в отдельные слои. Меня зовут Рамиль Куватов, я разработчик в VK Tech, и эта статья — попытка описать и систематизировать принципы, которые помогают нам сохранять архитектуру чистой, а систему — устойчивой к изменениям.
DevOps съел архитектора? Как тикеты убили системное мышление
Вы узнаете:
🔻 Почему техдолг - не баг, а финансовый дериватив (модель ΔProfit = -€14.3M)
🔻 3 реальных коллапса: AWS S3, Facebook DNS, Cloudflare BGP - и что их объединяет
🔻 Как техлиду внедрить архитектурный фаервол без ссор с продактом (практика Netflix/Google)
🔻 Почему "карта глубины" важнее KPI релизов (и где взять 15% времени на рефакторинг)
"Когда стоимость ошибки падает - исчезает инженер. Но щелчок предохранителя всегда громче, чем тикет"
Серия статей с очередным разбором MV* шаблонов, но с интересными деталями
Даже опытные разработчики смогут найти что-то новое для себя
Это четвертая статья из серии,
в которой разбираем как собирается MVI и что же такое Model
Статья 4: Готовим MVI
- 🧩 Собираем MVI-пазл воедино
- 🤔 А что если вообще написать свою реализацию MVI?
- 📜 Ты так и не понял, что такое Model?
Всем привет, меня зовут Миша, и я разрабатываю платформу Яндекс Еды. Первые компоненты были написаны почти 10 лет назад (когда Еда ещё была стартапом Foodfox), и у нас накопилось много кода, который просто хорошо работает, а иногда даже «работает — не трогай». Но в процессе развития и устоявшиеся части системы нужно трогать, про что мои коллеги уже писали — как мы повышали версию PHP, пилили монолит и снимали нагрузку с БД.
Наконец настал черёд рассказать про процессинг заказов доставки еды из кафе и ресторанов (а также продуктов из магазинов и многого другого). За годы эволюционного развития он значительно разросся, что стало заметно затруднять дальнейшее развитие — например, изменения, связанные с выходом на новые рынки, — а также влиять на надёжность.
Поэтому мы решили вынести процессинг заказа в отдельный специализированный сервис. Чтобы определить, что выносить, а что оставлять, нужно было составить исчерпывающий и актуальный список процессов, которые происходят с заказом. И здесь мы столкнулись с вызовом: это знание распределено по многим людям и документам, поскольку на протяжении долгого времени в процессинг заказов вносили изменения многие команды. И перед нами встал вопрос — как собрать нужную информацию о системе с заметной долей легаси быстро, да так, чтобы информация была актуальна?
Привет! Меня зовут Азамат, я backend-разработчик в Циане. В работе мне часто приходится пересматривать архитектуру компонентов или проектировать её с нуля. Со временем у меня накопились подходы и наблюдения, которыми хочу поделиться.
В этой статье расскажу, с чего я обычно начинаю проектирование, какие вопросы задаю себе перед тем, как описывать архитектуру, и какие принципы помогают принимать решения.
Материал будет полезен тем, кто хочет влиять на архитектуру в своей команде и ищет, с чего начать.
Flowable Async Executor (также известный как Job Executor) — это ключевой компонент Flowable. По сути, это многократно используемый, автономный компонент, работающий внутри различных движков Flowable и обеспечивающий асинхронное выполнение логики.
Вследствие кропотливой, многоэтапной работы проектировщиков и всей команды проекта на свет появился некий результирующий продукт - Требования к целевой Информационной системе. На каждом этапе в качестве входящих ресурсов мы использовали результаты предыдущих, наращивая шаг за шагом понимание и представление о том целевом продукте, который мы должны получить, в результате реализации проекта.
Теперь наступил момент кульминации, когда мы можем специфицировать Требования, взяв за основу все те артефакты, которые получили в процессе проектирования.
Для чего это необходимо делать?
Все полученные артефакты складываются в стройную и полную модель прототипа целевого продукта только в реальности проектировщиков. Если же взглянуть на результат проектирования отстраненным взглядом команды, которой предстоит воплощать эту модель в коде, то окажется, что в общей картине не хватает множества разъяснений, стыковок, структурированности, последовательности исполнения и тому подобного.
Опять же часто команда разработчиков не в полном объеме обладает способностью чтения диаграмм в разных нотациях. А потому их содержание должно быть переведено в более понятное представление, по возможности систематизированное в форме, близкой к структуре задач, поэтапное выполнение которых командой и приведет к тому самому целевому продукту.
Всем привет! Меня зовут Андрей, уже несколько лет я работаю тимлидом/техлидом в разных компаниях и различных проектах. В последнее время подход Domain Driven Design у всех на слуху. Хотя этот подход развивается уже много лет (с 2003), только сейчас на него обращают активное внимание и многие команды пробуют внедрять его у себя.
В этой статье я бы хотел рассказать об ошибках, возникших в процессе внедрения DDD в проектах с моим участием, и рассказать о подводных камнях, с которыми мы столкнулись при реализации, и о которых, к сожалению, мало говорят в книгах и руководствах. Возможно, это поможет вам правильно построить процесс внедрения и развития проектов с использованием подхода DDD.
«Будем отправлять события в Rabbit!» Фраза, которая выдает мышление, рождающее код, полный боли. К сожалению, я ее часто слышу. Поэтому, уже много лет размышлял о написании этой статьи и безумно рад, что у меня, наконец, дошли до нее руки.
В статье я расскажу, как смешение понятий события, сообщения и транспорта рождает возгласы типа «Я ненавижу использовать Symfony Messenger, потому что был у меня проект на нем, и он не взлетел!»
Будут косвенно затронуты компоненты Symfony Messenger и Event Dispatcher. Несмотря на это, данный материал может оказаться полезным и для разработчиков, использующих другие фреймворки и даже другие языки.
Как вы думаете, нужно ли архитектуру на вашем текущем проекте подвергнуть масштабному пересмотру и исправлению? Ставлю на то, что большинство читателей ответят положительно. И эта часть именно про это. В ней мы рассмотрим:
1. Когда сложившаяся архитектура подлежит масштабным изменениям.
2. Что не менее важно, когда лучше оставить, как есть.
3. Ключевые признаки проблем в архитектуре.
4. Основные способы исправления таких проблем.
Но для начала мы вспомним, что было в предыдущих сериях. В первой части мы прошлись по теории и выяснили:
1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично;
2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура;
3. Что самое важное свойство архитектуры — максимальная независимость команд друг от друга;
4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling — характеристика связи двух точек системы/кодовой базы; а cohesion — характеристика того, насколько плотно упакованы такие связи в компоненты.
Во второй части мы уже перешли к практике построения архитектуры с нуля. Мы узнали:
1. Что попытки угадать с архитектурой до старта проекта обычно проваливаются.
2. Что маленькие команды работают буквально в разы эффективнее, чем большие.
3. Что лучший способ разделить софт между командами - делать это постепенно. Начать с одной команды и уже затем дробить систему по обнаруженным в процессе разработки границам.
Теперь перейдем к вопросу, что же делать, если «все уже украдено до нас».
Краткий разбор моего опыта обучения на Яндекс.Практикуме и как я решил поменять свою жизнь и выбрать другую дорогу личностного и профессионального развития.
— Отличная работа, Егор! Я вам на почту правочки прислал по прототипу. Взгляните.
У меня от этой фразы что-то внутри ёкнуло. Захожу в почту, к письму прикреплён вордовский документ (на дворе 2009 год). Открываю… 55 комментариев. Пронумерованных. На четыре страницы.
Пробегаюсь по списку. Часть из них вносятся буквально за пять минут. А часть — перечёркивают мою двухнедельную работу.
Я откинулся в кресле, посмотрел в потолок. «Что не так с этим клиентом?». Нет, неправильный вопрос. «Что я делаю не так?». И, главное, как мне не оказываться в таких ситуациях в будущем?
Сегодня, спустя 15 лет, я знаю ответ на эти вопросы. И сейчас попробую уместить в одну статью почти всё необходимое для того, чтобы клиенты, начальники и коллеги принимали результат работы проектировщика (или дизайнера) с первого раза.
После того как мы при помощи разнообразных способов «объяснения неопределенности» собрали полную картину об исследуемой предметной области, можно прейти к формированию единого представления, описывающего предмет цифровизации. Для этого все формулировки, модели, алгоритмы и прочие артефакты необходимо систематизировать в виде структуры Требований к системе.
Как обычно зададим цели на следующий этап работ: На основании собранной информации о целевом продукте подготовить качественные требования, позволяющие максимально эффективно организовать процесс их их согласования и реализации.
Примечание: Этот пост является продолжением предыдущего, так как многие читатели спрашивали, что происходит, когда у асинхронных заданий заканчиваются попытки повторного выполнения.
