Russian Association of Software Architects
4.34K subscribers
85 photos
9 videos
15 files
296 links
Канал самоуправляется коллегией: @sergey486 и @emacsway . Бот для вступления в авторский коллектив: @ru_arc_bot

Предложить доклад для митапа: @ru_arc_meetup_bot

Группы:
@ru_arc_chat
@rasa_business
@archicases

Рекламу не размещаем.
Download Telegram
Забрал самые первые экземпляры, прямиком со склада :)
🔥67👍148
Russian Association of Software Architects
Забрал самые первые экземпляры, прямиком со склада :)
Сразу всем отвечу по поводу купить, - их в Москву на склад только вчера вечером привезли, уже на этой неделе по идее должны появиться в продаже, по крайней мере уже точно развозят по маркетплейсам.

UPD: появилась в продаже

https://bhv.ru/product/izuchaem-ddd-predmetno-orientirovannoe-proektirovanie/
👍22
Russian Association of Software Architects
Забрал самые первые экземпляры, прямиком со склада :)
Если заметите опечатки, пишите мне в личку (@sergey486), я все форвардну издательству. В следующем тираже все будет исправлено.
👍6👌1
1. Как делать микросервисы единообразными, когда их много, а разрабы все разные? — Олег Козырев, Авито
У нас было несколько десятков микросервисов, и их число продолжало расти. Всё бы ничего, но когда один сервис написан так, как привыкли писать на PHP, другой вдохновлен Ruby, а третий и вовсе отдаёт плюсами, то становится жутко. С таким зоопарком подходов переключаться от сервиса к сервису очень сложно и трудозатратно, а главное, чревато большим количеством ошибок в разработке. Поговорим о проблеме и ее решении.

2. Paranoia driven development — Мясников Алексей, Яндекс
Как спроектировать контракты так, чтобы не допускать ошибок при их использовании. На нескольких примерах мы пройдем путь от ненадежных контрактов к надежным. На всех этапах дизайна кода будем исходить из того, что кодом будут пользоваться самые "одаренные" программисты.

3. Микросервисы в небольших командах разработки: почему вам нужен PaaS? — Алексей Коротин, Sports ru
Какие проблемы поможет решить PaaS? Архитектура компонентов и как организовать миграцию старых сервисов на новые рельсы.

4. Обработка ошибок в go в 2023 — Виталий Попов, InDrive
Доклад дает конкретный алгоритм выбора способа обработок ошибок в go для проекта. Плюс маленький обзор пакетов, существующих, для каждого из способов.



🗓 8 ноября, начало в 19:00 мск, Среда

🌐 ОНЛАЙН

Регистрация на мероприятие
👍81🔥1
Скоро очередной движ подлодки по архитектуре, запрыгивайте, кому интересно 🙂

https://podlodka.io/techcrew
👍7
Компания ScyllaDB проспонсировала открытую публикацию избранных глав из технического бестселлера Amazon Мартина Клепмана «Проектирование высоконагруженных приложений»:
https://lp.scylladb.com/designing-data-intensive-apps-book-offer

А мы перевели на русский язык 1-ю из этих избранных глав, посвящённую технологиям работы с данными, на которых построены современные СУБД и ответственные интернет-сервисы

Глава 3. Хранение и извлечение данных

Структуры данных, которые поддерживают вашу базу данных
- Хэш-индексы
- SST-таблицы и LSM-деревья
- B-деревья
- Сравнение B-деревьев и LSM-деревьев
- Другие индексные структуры данных

Транзакционная обработка или аналитика?
- Хранилище данных
- Звезды и Снежинки: схемы для аналитики
- Агрегация: Кубы данных и материализованные представления

Столбцово-ориентированное хранилище
- Сжатие столбцов
- Порядок сортировки в хранилище столбцов
- Запись в столбцово-ориентированное хранилище

https://systems.education/designing-data-intensive-applications

#книги #архитектура
👍21
Forwarded from Блог Сергея Баранова (Sergey Baranov)
Кто использует https://raml.org для API?
Поделитесь впечатлениями.
👎3👍1
Кратко о fitness functions. Любое приложение всегда стремится к энтропии. Как говорил известный в ИТ-индустрии Gregor Hohpe:

💬 It’s almost like enterprise IT is subject to the Second Law of Thermodynamics, which concludes that the entropy in an (isolated) system can never decrease - at best it can be constant, but usually it increases.
-- "Here’s why enterprise IT is so complex" by Gregor Hohpe

Технически невозможно контролировать качество работы каждого разработчика. Это побуждает индустрию искать способы поддержания качества архитектуры на принципиальном уровне. Одним из таких способов является Evolutionary Architecture.

Генетический механизм репродукции реализует адаптивный способ разрешения неопределенности.

Причина его существования заключается в том, что никто не знает какие условия обитания будут на планете завтра. Т.е. имеет место неопределенность условий существования. Вдруг завтра прилетит метеорит и изменится состав атмосферы?

В связи с этим, двуполое размножение обеспечивает постоянную генерацию новых генетических комбинаций. Мы просто не знаем какая именно генетическая комбинация окажется наиболее приспособленной к завтрашним условиям окружающей среды.

Те генетические комбинации, которые слабо приспособлены к текущим условиям окружающей среды, не должны препятствовать распространению более приспособленных комбинаций. Иными словами, если существует механизм формирования разнообразия генетических комбинаций, то должен существовать и механизм истребления слабо приспособленных генетических комбинаций. Именно поэтому двуполый механизм репродукции не может выполнять свои функции без хищников, назначение которых сводится к истреблению слабо приспособленных генетических комбинаций. Т.е. к селекции. Это как пропалывание грядки.

Зачастую проблема кодовой базы заключается в том, что никто и ничто не выполняет роль этого самого хищника, истребляющего несоответствующие решения. Поэтому больные решения хорошо размножаются.

Robert Martin говорил, что архитектура - это о том, как не надо делать. Иными словами, архитектурное решение - это сокращение количества возможных вариантов. Т.е. архитектура должна выполнять хищнические функции.

Чем отличаются собаки от волков? Волк имеет естественных врагов-хищников, а собаки - нет.

Вместо хищников, процесс селекции собак выполняют выставки и стандарты пород, которые фиксируют желаемые свойства пород.

Выводок, не соответствующий требованиям стандарта породы и допустимым пределам отклонения, отбраковывается и не получает сертификат соответствия. Его рыночная ценность падает, и он не используется заводчиками для репродукции.

По мере возникновения исторических изменений в породе, в стандарт вносятся изменения, требования ужесточаются, что обеспечивает прогресс породы.

Этот же принцип положен в основу Evolutionary Architecture. Архитектор выступает в роли автора стандарта породы, а разработчик - в роли заводчика, который выбирает (путём сравнения) для репродукции такой экземпляр породы из всех возможных, который наилучшим образом соответствует стандарту.

Роль стандарта породы выполняют fitness functions (функции соответствия, приспособленности). Они позволяют разработчикам измерить степень соответствия старого варианта системы и нового, и выбрать тот, который соответствует требованиям наилучшим образом.

Понимая, что требования fitness functions будут ужесточаться, разработчик всегда стремится увеличивать запас по требованиям , что вынуждает искать его новые решения и постоянно повышать собственный уровень знаний.

Хотя fitness functions выполняют охранные функции, препятствуя деградации свойств системы, главная их ценность заключается не в этом, а в создании благоприятных условий для постоянного развития уровня квалификации специалистов.

Наиболее важными я считаю fitness functions с нагрузочным и объемным тестированием, которые мгновенно выявляют костыльные запросы и побуждают разработчиков изначально закладывать в систему решения с дальним горизонтом развития, например, такие, как CQRS.

Пример реализации fitness functions.
👍9🔥31👏1
Админ би лайк
🤣14🔥3👍1
Друзья, есть запрос про проведение Customer Development по теме AI.

Если вы пробовали в своей работе AI (успешно/не успешно) или планируете попробовать и готовы пройти небольшое интервью на эту тему (получите новый опыт в качестве респондента 🙂 ), то напишите об этом в личку @akimovpro, все детали у Игоря

Спасибо.
👍4
Через 5 минут ArchDays MeetUp.

Тема: «Сага - решение технической проблемы или доменный процесс?».

🟢 Михаил Натаров, расскажет: если поискать доклады про саги, то они делятся на два типа. В первом говорят, что саги - это про распределенные транзакции. Во втором - что саги это описание процессов в домене. В докладе спикер поделится плюсами и минусами каждого из подходов, и вместе посмотрим на примерах когда "контекст и движок", а когда это скорее про DDD и "доменные саги".

🔜 Ссылка на трансляцию
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥32
Кто читал, что скажете о книге?

Ссылка: https://www.manning.com/books/building-user-friendly-dsls
Поступил запрос:

Нужен внешний архитектурный наблюдательный совет, – проверять наши решения на корректность, предлагать альтернативы.

В таком подходе есть перспектива, обсудили узким кругом, краткое саммари обсуждения.

Кто желает, может высказать свое мнение, риски, предложения.

Консультативный совет, как площадка для дискуссий и выработки предложений

Организационные задачи
⁃ Прописать функции и компетенции
⁃ Прописать перечень рассматриваемых вопросов
Например: рассмотрение ИТ-стратегии перед утверждением, рассмотрение опер модели ИТ, определение политики управления технологиями
⁃ Прописать структуру подчинения и эскалации
⁃ Описать схему работы
Например: мониторинг принимаемых внутренним органом решений с возможностью эскалации

Риски
⁃ Требование проектирования без работ по проектированию на уровне «скажите нам как надо»
⁃ Не вовлеченные в повседневную работу люди будут восприниматься как противники, как следствие - возможен саботаж
⁃ Интересы совета будут расходится с интересами команды
⁃ Отсутствие полного контекста снижает возможности по обоснованию решений и доверию к ним
⁃ Контекст меняется быстрее погружения в контекст

Условие
⁃ Не должно быть прессинга на внутренних специалистов
👍3
Не прошло и трех дней

Бывший глава OpenAI, компании-разработчика чат-бота с искусственным интеллектом ChatGPT, Сэм Альтман перейдет на работу в Microsoft. Об этом сообщил глава корпорации Сатья Наделла в X (бывший Twitter).

Он возглавит новую исследовательскую группу по передовым технологиям на базе искусственного интеллекта, вместе с ним в компанию перейдет бывший президент Open AI Грег Брокман.
😁4🤔3😐1
Удалось ли вам существенно улучшить хотя бы один legacy проект (новый не считается) на последних трех местах работы? Учитывается архитектура, состяние кода, качество процессов, топология команд, коллектив.
Anonymous Poll
16%
да, полностью
55%
частично
17%
нет, кровавый ентерпрайз оказался сильнее
11%
даже не пытался заниматься донкихотством
Russian Association of Software Architects
Удалось ли вам существенно улучшить хотя бы один legacy проект (новый не считается) на последних трех местах работы? Учитывается архитектура, состяние кода, качество процессов, топология команд, коллектив.
Коллеги, спасибо за участие в опросах. На текущий момент видно, что при смене работы специалист с вероятностью 50% попадает в неудовлетворительный проект. При этом треть опрошенных оказались недостаточно подготовленными хотя бы частично исправить ситуацию.

Тем не менее, каждому пятому удалось реализовать свой замысел полностью. Нашлось 58 человек, обладающих опытом, который, как мне кажется, был бы интересен остальным. Предлагаю этим опытом поделиться с остальными. Вот вы приходите на новый проект и видите лапшу, бардак, отсутствие документации, давление сроков и напряженность. И возможно, кто-то из окружения не в восторге от привлечения с рынка труда экспертизы на то место, на которое он рассчитывал. Каков ваш алгоритм действий? Как ориентируетесь в ситуации? Как узнаете систему? Как пускаете корни в коллективе? Как работаете с недоброжелателями? Как находите время на проработку целевой архитектуры? Как разгребаете рутину? Как изыскиваете ресурсы на устранение гэпа? Как внедряете изменения? Встречаете ли сопротивление и как работаете с ним? Как подготавливаете разработку для реализации решений? Как изменяете процессы? В какой последовательности это все делаете и почему?
🔥9🤔2🤯21👍1
Уже в этот четверг к нам в гости придет Влад Хононов, автор книги «Изучаем DDD — предметно-ориентированное проектирование»

Получить ссылку на трансляцию👈

Влад инженер-программист, архитектор с более 20 лет опыта в небольших и крупных компаниях, в разных ролях — от вебмастера до главного архитектора.

Возможно, вы уже читали его книгу «Что такое предметно-ориентированное проектирование?», которую мы недавно перевели для вас и выложили на сайте Systems.Education — читать👈

Хотите задать вопросы по книге или узнать о DDD из первых рук? Приглашаем всех.

Кому может быть особенно интересно:

🧑‍💻Разработчику корпоративного программного обеспечения

👩‍💻Системному аналитику

👨‍💻Архитектору ПО

Начало в 19:00 МСК
Интервью на русском языке.

Получить ссылку на трансляцию👈

Domain-Driven Design — подход к проектированию систем, основанный на создании в проекте общего языка между заказчиками и разработчиками. Этот язык используется как для моделирования предметной области, так и для создания и именования объектной структуры программной системы, включая разбиение её на части, что особенно актуально для современной разработки.

Получить ссылку на трансляцию👈
👍9🔥3
Russian Association of Software Architects
В последнее время многие обсуждают DDD, но не все понимают что это такое. От этого страдает качество подобных обсуждений. И найти внятное определение DDD в литературе, действительно, непросто. Ниже приводится определение DDD от первоисточника: I. Putting…
Каноническое определение DDD, прямо скажем, понятности не добавляет. Даже если его кто-то прочитает и мы попросим его пересказать своими словами, то из этого вряд ли что-то получился.

После долгого коллективного исследования (в рабочей группе) вопроса моделирования в DDD, я пришел к выводу, что наиболее удачным определением DDD было бы это:

💬 MODEL-DRIVEN DESIGN discards the dichotomy of analysis model and design to search out a single model that serves both purposes.
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans

Можно сутками объяснять, почему именно это определение, но более точного я пока еще не встречал.
👍5🔥21