Предметно-ориентированный подход (DDD, Domain-Driven Design) в проектировании программного обеспечения является наиболее эффективным способом моделирования бизнес-процессов. Сегодня мы поговорим о стратегическом и тактическом проектировании, после чего рассмотрим инструмент ускорения проектирования под названием «событийный штурм» (event storming).
Твёрдо и чётко. Это цитата из доклада Алексея Курзякова на Alfa LevelUp Day в Екатеринбурга, где мы открыли новый IT-хаб. А это значит — самое время провести в новом офисе новый митап в новом формате с докладами и воркшопом. На двух параллельных треках провели оффлайн-воркшоп и поговорили о новых фичах, инновациях и росте: как создать фреймворк, как из мидла вырасти в тимлида, как в кратчайшие сроки создать новую фичу и не словить аварию, как в кризисных условиях создавать сервисы и как упаковывать тяжелые монолиты в удобный интерфейс.
Под катом краткая выжимка докладов, ссылки на видеозаписи и фотоотчёт.
Все, кто занимается разработкой микросервисов, так или иначе решают для себя вопрос: как обеспечить согласованность бизнес-транзакций, в которых участвуют данные нескольких сервисов. Разумеется, лучшее решение - отсутствие такой необходимости. Но не всегда это возможно.
Один из признанных ИТ-сообществом ответов - это, так называемый Saga паттерн. О том, что это такое, написано достаточно много, а мы займёмся его реализацией.
В статье рассказал, как в рамках разработки нового сервиса мы выбирали оптимальный вариант стратегии ребалансировки Kafka и изучали влияние различных стратегий ребалансировки на потерю сообщений.
Привет! Меня зовут Артем Коньков, я frontend-разработчик в СберМаркете. А еще, я тот человек, который в фильмах ужасов спускается в темный подвал вопреки инстинкту самосохранения. Во-первых, потому что это интересно, а во-вторых — кто-то же должен это делать!
Это история о том, как мое любопытство превратило небольшую задачу в настоящий квест длиной в 5 спринтов. Надеюсь, мой пример поможет вам меньше бояться подобных задач, и даст мотивацию копать глубже. А в конце статьи я расскажу, как правильно закреплять результаты, чтобы такая масштабная работа не была проделана впустую. Но сначала немножко контекста.
Привет! Сегодня поговорим про один из множества проектов, реализуемых на базе Единой информационной системы жилищного строительства ДОМ.РФ (ЕИСЖС) - конструктор государственных региональных программ поддержки. Я, главный специалист Артём Емельянов, расскажу, что это такое, какая связь между государственными региональными ипотечными программами поддержки и зачем нужен конструктор.
Государственные региональные ипотечные программы поддержки помогают улучшить жилищные условие за счет разных льгот при покупке жилья. Они могут быть направлены на поддержку определенных категорий населения, таких как молодые семьи, ветераны, многодетные семьи, или на общую поддержку жилищного строительства и рынка недвижимости. Более детально со списком государственных региональных ипотечных программ поддержки можно ознакомиться в нашем консультационном центре ДОМ.РФ.
Программы могут включать в себя финансовую поддержку, например, субсидии на первоначальный взнос, возмещение недополученных доходов кредитным организациям, снижение процентных ставок по ипотечным кредитам, льготное кредитование, а также другие меры, направленные на стимулирование жилищного строительства и рынка недвижимости. В перспективе планируется цифровизировать как минимум по одной региональной программе в каждом регионе страны.
ДОМ.РФ здесь - оператор программ, направленных на поддержку жилищного строительства и доступности ипотечных кредитов для населения. Мы разрабатываем ипотечные продукты и услуги, которые могут быть использованы в рамках этих программ, снижаем риски кредитования, предоставляем гарантии и страхование, а также работаем с банками и застройщиками для повышения доступности жилья.
Здравствуйте, меня зовут Дмитрий Марков. Я архитектор направления в Альфа-Банке. В этой статье мы поговорим об архитектуре, как ни странно. Без космических «прорывов» и «аналоговнет». Всё жизненно.
Зайдем с разных сторон, проведем параллель с реальностью, даже, может, улыбнемся местами. И посмотрим и на рабочий пример архитектурной концепции, продиктованной определенными реалиями.
Материал предназначен, прежде всего, читателю, который интересуется архитектурой и разработкой, тому, кто ищет опыта коллег по цеху и их соображения, тому, кто уже что-то читал и, возможно, даже успел набить кое-какие шишки, задев мизинцем дверные косяки действительности.
Тут у нас с вами будет про условия/проблемы, про концептуальное решение со сменой технического стека, про аутентификацию, авторизацию, API-шлюз и, конечно же, немного про микро- и макросервисы, куда ж без них.
Надеюсь, из статьи вы заберете определенный положительный опыт с изложением хода мыслей автора о том, почему мы все скомпоновали именно так.
За окном 2023 год, а среди разработчиков только и разговоров, что про микросервисы да API First. Несмотря на то, что эти темы не новы, похоже, что их актуальность даже набирает обороты.
Про микросервисы уже много написано и теоретического и практического. Есть у этого подхода и свои евангелисты (Microservice Architecture) :) В целом это тема достаточно холиварная, особенно при крайних точках зрения. Сегодня мы ее отложим, но обязательно вернемся в контексте темы этой статьи. Конечно, это будет не менее обсуждаемая история, посвященная методологии API First и программным интерфейсам (прежде всего, web, но не только) при проектировании и разработке современных информационных систем :)
Меня зовут Антон, я руководитель Архитектурного комитета в компании SimbirSoft. Мы используем подход API First для проектов самой разной направленности, где есть несколько команд разработки (как минимум Backend и Frontend), а также при высокой неопределенности на этапе реализации (быстроменяющиеся требования и цели, параллельные процессы проектирования и реализации, высокие запросы к TTM и так далее).
Поскольку API First не является чем-то новым для многих команд разработки, то мы решили не писать про то, что все уже знают, а остановиться на отдельных вопросах и разобраться в практическом аспекте применения методологии API First в части проектирования, прототипирования и разработки.
Этот материал открывает цикл статей, посвященных практическому внедрению методологии API First в разработку наших команд. Если быть точным, то мы отдаем предпочтение «младшему брату» API First, практикующему проектирование (design), — известному как Design API First. Чтобы избежать путаницы, далее термин «API First» будет обозначать подход к разработке ПО, а термины «Design API First» и «Design First» – проектирование ПО в рамках подхода API First.
2 часть: Как мы внедряли Design API First. Показываем на примере сервиса аутентификации
3 часть: Интеграция паттерна Design API First в конвейер разработки ПО: наш опыт
4 часть: Как генерировать модели интерфейсов на основе спецификации на стороне frontend-приложений
Привет, с вами команда разработки dBrain.cloud! Хотим поделиться историей миграции с Elasticsearch Beats Kibana (EBK) на Grafana Loki. Предпосылок перехода было немало: замена EBK лицензии Apache 2.0 на ограниченную SSPL 1.0, растущее потребление ресурсов, объемы требуемого места в хранилище и др. Сегодня покажем, как из грамотно подобранных и поселенных под одной крышей продуктов получилось собрать единый стек логирования и мониторинга.
В данной статье будет описано, как создать простой kafka producer и kafka consumer, а затем протестировать их.
Уверен, что многие, кто интересовался подходами к разработке микросервисной архитектуры, знакомы с трудами Криса Ричардсона на эту тему и уже встречали transactional outbox pattern. А для тех, кто не знаком, кратко расскажу основную идею:
В микросервисной архитектуре не редка ситуация коммуникации микросервисов посредством публикации событий. Происходит изменение состояния какой-либо сущности в одном из микросервисов и для информирования других сервисов публикуется событие об изменение данной сущности. Проблема кроется в том, что эти два действия - сохранение состояния и публикация события - обычно не происходят атомарно. А это означает, что на любом из указанных этапов что-то может пойти не так, и одно из действий не будет выполнено, что оставит систему в несогласованном состоянии.
Всем привет, меня зовут Полина, я техлид команды, занимающейся проектом электронного документооборота в среднего размера продуктовой компании. В этой статье я расскажу как мы обнаружили в привычном инструменте мониторинга ошибок - Sentry - распределенную трассировку и опробовали ее для своих задач. Примеры в статье приведены для конкретного стека, это python3 и FastAPI, храним мы данные в MongoDB, используем RabbitMQ.
Статья будет полезна скорее для тех, кто уже использует Sentry, водится с микросервисами, но еще не пришел к распределенной трассировке, и скорее для небольших, средних или только начинающихся проектов.
Трейсинг (возможность отслеживания пути запроса между сервисами в микросервисной архитектуре) - критический важное требование функционирования более-менее крупных систем.
У Uber - тысячи микросервисов. А у Netflix - несколько тысяч
В каком сервисе возникла ошибка? Сервис упал или просто ошибка сети? Что за ошибка возникла?
Стоп!
Рим не за один день был построен
Поэтому начнем с малого и подключим трейсинг к обычной микросервисной системе на ASP.NET Core.
Поможет нам в этом OpenTelemetry
Как не утонуть новичку в документации nx?
Разберем основные понятия и концепции по работе с монорепозиторием под управлением nx.
А также укажу некоторые особенности о которых нужно знать, чтобы "не выстрелить себе в ногу".
Ключевой идеей микросервисов является возможность независимого изменения и развертывания отдельно взятой функциональности. Фактически, микросервисы - это еще одна форма модульной декомпозиции. Навыки правильного выделения границ модулей являются ключом к построению успешной микросервисной архитектуры. Выделяют три ключевые концепции, определяющих качество границ микросервисов.
Всем привет, на связи Юджин, (теперь уже) беспризорный backend-разработчик на Go. Сегодня я расскажу вам забавную и больную историю о том, как мы монолит распиливали. Кто-то, может, посмеётся, а может, найдёт в этом себя.
Привет, Хабр! Команда Учи.ру традиционно подводит итоги учебного года. Для нас — это сезон не только крупных продуктовых релизов, но и изменений под ИТ-капотом Учи.ру. Сегодня команда поделится, что нового произошло в архитектуре и разработке платформы и что сподвигло их на эти изменения.
