Архитектоника в ИТ

Сегодня будет сказ про оптимистичную архитектуру. В нём можно разглядеть себя или своих знакомых. Основано на реальных событиях, но все совпадения случайны! Однажды перед разработчиками встала задача — разработать микроядро для хранения документов клиента. Функциональность подразумевала создание CRUD-сервиса и сервиса поиска. Поиск должен был предоставлять возможность находить документы выбранного клиента по произвольному фильтру, который строился на основе атрибутов документа. Архитекторы решили не ограничивать API поиска, предоставив будущему пользователю абсолютную свободу действий...

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

Необходимость интеграции с внешней системой — для многих это уже рутина, будни распределённых систем. Мы интегрируем сервисы/микросервисы, разные домены, встраиваем чужие решения в свои или наоборот. Однако что может пойти не так в давно работающей интеграции? Сначала сформулирую капитанские тезисы, а потом перейду к истории из реальной практики. *** Имеется давно работающая интеграция между двумя системами. Первая — внешняя — отвечает за идентификацию человека по его персональной информации и присваивает ему уникальный идентификатор (назовём его PersonID)...

Доказано, что каждая снежинка имеет уникальную структуру. Разработчики Twitter вдохновились этим феноменом и изобрели Snowflake ID — целочисленный глобально-уникальный идентификатор. Проблематика хорошо описана в моём предыдущем посте про Lamport Timestamp, поэтому здесь сразу перейдём к основной части. Структура 64-битного идентификатора (от старшего бита к младшему): В зависимости от потребностей размерность полей может варьироваться. Например, если требуется более длительное хранение данных (более 69 лет), можно увеличить размерность поля Timestamp...

На нижеследующие мысли меня навела статья с говорящим названием "Microservices antipatterns and pitfalls", которую написал Mark Richards. Особенно интересными мне показались дополнительные способы проверки границ микросервисов. Если вы собираетесь переходить или уже перешли на микросервисную архитектуру, то вам должно понравиться. В чём заключается функциональность сервиса? Письменный или устный ответ на этот вопрос — отличный способ понять, перегружен ли сервис. Чем чаще в описании встречаются соединительные...

Недавно я узнал об инструменте Zonky, который на одном из проектов позволил ускорить выполнение интеграционных тестов в среднем в 3.5-4 раза. Делать практически ничего не пришлось: подключил зависимость и добавил аннотацию. Если вы испытываете проблемы с долгим выполнением интеграционных тестов, пишете на Java/Kotlin, используете Spring (не обязательно) и Testcontainers, то сможете за пару часов повторить мой опыт и проверить эффективность использования Zonky в своём проекте. У меня есть страсть — узнавать происхождение необычных слов...

Если 10-15 лет назад рассказывали, что такое технический долг, почему он возникает и как может повлиять на дальнейшую разработку, то сейчас начали рассказывать, как с ним бороться. Очевидно, за прошедшие годы многие сильно задолжали. :) Судите сами, на прошедшей конференции TechLeadConf 2025 около 30% докладов была посвящена борьбе с техническим долгом и замене Legacy. В конце статьи я привел список из 8 докладов (всего было 27), которые раскрывают эту тему с разных сторон. Каждого волнует вопрос,...

Мы привыкли к тому, что ведем разработку, используя лучшие инженерные практики, включая настройку CI/CD-конвейера. Сначала код проходит многоэтапные стадии проверки и тестирования, а только потом попадает в production-среду. Давайте представим ситуацию, что нужно запустить код, минуя все эти стадии. Прям в production-среде. На первый взгляд — бред! Но если подумать, то на самом деле не такая уж редкость. Например, некоторые системы предоставляют своим пользователям возможность расширять функциональность за счет прикладных скриптов...

Данные — это фундамент большинства систем. Они эволюционируют вместе с кодом и архитектурой: происходит развитие способов хранения и работы с данными. Миграция данных всегда сопряжена с риском их потери и нарушения работоспособности системы. А если речь заходит о смене БД, риски и сложность миграции возрастают на несколько порядков. В том числе по этой причине многие основательно подходят к выбору БД: фундамент должен быть прочным, его должно хватить надолго, он должен выдерживать нагрузку с хорошим запасом...

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

Сегодня хотел бы поднять тему Legacy. Но не про то Legacy, которое человек получает по наследству от богатого родственника, а про другое, с которым мы часто сталкиваемся в ИТ, и которое имеет негативную коннотацию. Всё началось с того, что я наткнулся на текст Patterns of Legacy Displacement. С одной стороны, это статья, в которой в общих чертах и с разных сторон рассматриваются проблемы модернизации Legacy-решений. С другой стороны - это подборка вполне конкретных шаблонов модернизации, ссылки на описание которых приводятся по мере повествования...

Сегодня я хочу поделиться опытом и наблюдениями в рамках одной очень сложной и интересной задачи. Производим тестирование механизма миграции данных из одной базы данных в другую. Объем очень большой, а модели источника и приемника сильно отличаются. Вместе с этим стоит вторая задача — убедиться, что копирование выполнено корректно. Самое первое, что приходит в голову, — сравнить количество строк/записей/документов источника и приемника. Действительно, с одной стороны, если модели хранения источника и приемника подобны, то вариант вполне рабочий...