Анализ и проектирование систем *

Привет, Хабр!

На протяжении нескольких лет одной из наиболее популярных и важных книг в нашем арсенале остаётся книга Влада Хононова «Изучаем DDD предметно‑ориентированное проектирование». Мы регулярно контактируем с Владом и надеемся, что вскоре сможем опубликовать здесь и развёрнутое интервью с ним. А сегодня хотим предложить вам подробный и несколько критический обзор его книги, найденный в одном англоязычном блоге. Автор статьи не скрывает, что книга Влада не вполне подошла под конкретные задачи, которые автор надеялся с её помощью решить и упростить. Но при этом он настолько толково описывает саму парадигму, а также как именно и для каких целей её лучше использовать, что мы сочли её отличной и честной рекламой нашего бестселлера. Далее — авторский обзор от сеньора Факундо Оланы из Аргентины.

22 апреля 2026 OpenAI выложила Privacy Filter — маленькую открытую модель, которая ищет и маскирует персональные данные прямо на устройстве. Без облаков, утечек и горы регулярок. В анонсе — 97% F1, длинный контекст, восемь классов чувствительных сущностей и обещание мультиязычности.

Джонов из Айовы или Вошингтон Ди Си она находит замечательно, а что насчет Максима Улугбековича из Нижневартовска? А Галин Палны из Урус-Мартана? У меня возникло простое человеческое желание потестить все это в реальных условиях, поэтому я собрал небольшой бенч на русском и хочу поделиться разбором модели и результатами.

А результаты, мягко говоря, из коробки совсем не звездные.

Ваши данные врут. Не потому, что кто-то хотел вас обмануть, а потому, что вы им это позволили.

Всё выглядит правильно: модель обучилась, метрики зелёные, дашборд аккуратный. А потом бизнес-решение, принятое на основе этих данных, приводит не туда. В этот момент начинают проверять алгоритм, гипотезу или эксперимент. Но в большинстве случаев проблема была раньше — в данных, которые никто толком не подготовил.

Даже аккуратный дашборд может скрывать проблемы в данных, если этап подготовки был сделан формально.

Всем привет!

На одном из проектов я настраивал дашборд в Yandex DataLens, который объединяет данные о трафике из Яндекс Метрики с данными о заказах из CRM и позволяет анализировать доход в разрезе источников трафика.

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

Меня зовут Андрей Рыжик, я product owner BI-направления в компании «Белый код». Продолжаем серию обзоров российских BI-систем с поддержкой ETL для малого и среднего бизнеса. Ранее мы разбирали PolyAnalyst, Modus. Сегодня на очереди AW BI – система, которая позиционирует себя как «дружелюбная BI-платформа» с самой демократичной стоимостью на рынке.

Современный бизнес оказался в эпицентре информационного шторма. Каждый день рынок наводняют сотни обзоров и подборок ПО — созданных не экспертами, а контент‑креаторами, оснащёнными инструментами ИИ, но без качественной проверки фактов и пост-обработки полученного текста. Качество таких материалов стремительно падает: 87% публикаций содержат фактические ошибки или устаревшие данные...

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

Рассмотрим модель данных application model, которая потребуется в дальнейшем изложении и которая используется в паттерне CQRS.

Реализация архитектурного паттерна CQRS, используемого в приложении для функционала application logic, представляет собой набор классов наследников базовых классов QueryHandler / CommandHandler и набор классов данных, которые являются наследниками базовых классов Query / Command. Классы наследники Query / Command представляют собой модель данных application logic. Такую модель данных логично назвать application model.

Используя application model и другие известные модели данных слоёв приложения можно построить полную схему моделей данных многослойной архитектуры приложения.

Почти каждый человек в СНГ пользуется телеграмом, но не каждый задумывается о том, на каких костылях держится его любимая платформа. Всё начинается с «печатает...» в избранном, а заканчивается тем, что форумы — лишь иллюзия интерфейса.

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

Научно-исследовательский и проектно-конструкторский институт металлургического машиностроения АО «KO ВНИИМЕТМАШ», входящий в состав ПАО «Северсталь», внедрил решения nanoCAD для цифрового проектирования объектов промышленной инфраструктуры. В работе института задействовано ПО nanoCAD BIM Строительство и nanoCAD Облака точек. Внедрение позволило повысить точность цифровых моделей, ускорить подготовку документации и автоматизировать получение ведомостей материалов.

Переход на отечественную Платформу nanoCAD стал частью стратегии цифровизации проектирования «КО ВИИМЕТМАШ». Основной объем работ института связан с реконструкцией и развитием объектов в условиях сложившейся промышленной застройки, где архивная документация зачастую неполна или неактуальна.

Институт проектирует как железобетонные конструкции с детализацией армирования и закладных деталей, так и металлические — с проработкой узлов и соединений. При работе над объектами сложной и нестандартной геометрии, характерными для фундаментов под уникальное металлургическое оборудование, используются 3D-модуль и nanoCAD BIM Строительство. Созданные модели преобразуются в параметрические элементы с присвоением необходимых атрибутов, что делает возможным их последующее использование.

Для создания точных цифровых моделей специалисты «КО ВНИИМЕТМАШ» применяют результаты лазерного сканирования. Для обработки полученных данных и интеграции результатов в среду проектирования используют nanoCAD Облака точек, что дает возможность учитывать фактические габариты существующих конструкций, коммуникаций и оборудования...

У каждого специалиста в своей области есть профильное ПО. Даже для разработки ПО есть соответствующее ПО. И зачастую большинство специалистов не заботит «открытость» такого ПО. Более того, среди специалистов по разработке/моделированию спутников в России немало встречается авторских решений или решений, специально разработанных для конкретной организации. НО! дальше этого предприятия или даже отдела эти решения никуда не выходят.

Поэтому я хочу рассказать про моделирующую среду для анализа динамики полёта космического аппарата (КА) с открытым исходным кодом – «Проект 42» (далее просто «42»), который использую в своей повседневной профессиональной деятельности.

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

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

Попытки упростить процесс программирования нашли свое отражение в No-code платформах, представляющих визуальный конструктор для производства программных решений без навыков программирования. Антонимом данной ситуации является классическая кастомная разработка приложений. Тем самым мы блуждаем между крайностями: или просто, или сложно. Пытливый ум попытался найти баланс где-то посередине, предлагая Low-code платформы.

При моделировании систем управления иногда возникает ситуация, когда точная математическая модель объекта неизвестна. Законы его поведения либо слишком сложны, либо вовсе не определены. Но сам объект управления доступен, например в виде стенда. Тогда можно снять с объекта управления экспериментальные данные: измеренные входные и выходные сигналы системы. В таких случаях используется идентификация систем – построение математической модели динамического объекта на основе экспериментальных данных.

Не представляет сложности разработать интеграционный поток и «соединить два API». Настоящая работа начинается там, где в единую экосистему нужно связать десятки разнородных сервисов, каждый со своей логикой, форматом данных и графиком обновлений. В корпоративных средах любая нестабильность интеграции бьет по ключевым процессам, а последствия могут измеряться не только потерянными часами, но и потерянными клиентами. Чтобы enterprise-ландшафт работал как часы, нужны особые подходы к проектированию, устойчивые архитектурные решения и способы сохранять контроль над всей интеграцией на любом ее этапе.

Привет, Хабр! Меня зовут Андрей Чиграй, я архитектор ПО с 10-летним опытом проектирования и разработки корпоративных информационных систем. За это время повидал немало — как лучшие практики в индустрии, так и простые ошибки, грозящие превратиться в полный провал проекта. В этой статье разберу методологию проектирования интеграционных решений от обследования до внедрения, а также поделюсь шаблонами артефактов, которые можно использовать в работе. Надеюсь, информация будет полезна как практикующим системным аналитикам и разработчикам интеграций, так и руководителям интеграционных проектов. Погнали!

Всем привет, меня зовут Никита и я CEO VSL-BI. Мы с командой занимаемся внедрением BI-аналитики и автоматизацией сбора данных в компаниях разного масштаба.

В большинстве случаев к нам приходят с задачами внедрения аналитики в специализированных системах вроде Microsoft Power BI, Yandex DataLens или Apache Superset. Но за последний год заметно выросло количество запросов именно на BI-конструктор внутри Битрикс24.

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

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

Концепция эволюционной архитектуры (Evolutionary Architecture) — очень популярный в наши дни подход к проектированию программного обеспечения, при котором система способна адаптироваться и развиваться без потери функциональности. Этот подход подробно описан в книге «Эволюционная архитектура. Автоматизированное управление программным обеспечением» Нила Форда и др. 

На связи Кирилл Маканков, iOS-разработчик в ПСБ. В этой статье я хочу проанализировать эволюционную архитектуру сквозь призму теории Дарвина и определить, действительно ли этот подход позволяет ПО эволюционировать. 

Хабр, привет! Меня зовут Вячеслав Демин, я больше пяти лет работаю в сфере Data Science. Сейчас я руководитель направления аналитики данных в Сбере и эксперт на курсе «Специалист по Data Science» в Яндекс Практикуме. Начинал с этого же курса в 2020 году, после чего работал в сфере страхования и нефтехимии.

В этом материале я расскажу, для каких задач в Data Science использую ИИ и почему полагаться на него на 100% всё ещё не стоит.

«Фарш невозможно прокрутить назад» — этой поговоркой инженеры данных могли бы объяснить, как работает классический ETL. Ошибка может случиться на любом этапе: не тот коэффициент применили, не ту валюту подставили, забыли про скидку. Но после того как исходные данные трансформированы и отчет сформирован, но иногда бывают такие ситуации, когда вернуться к первоисточнику по какой-то причину уже нельзя. 

В FinOps эта ситуация — не метафора, а суровая реальность. Данные от облачных провайдеров доступны лишь в ограниченном окне (30–90 дней), а иногда и меньше. Если вы сначала обработали их, а потом поняли, что ошиблись, может так случиться, что перезапросить исходники уже не получится. 

В этой статье мы разберем два подхода к построению процессов обработки и преобразования данных — ETL и ELT — и докажем, почему для FinOps выбор ELT — это не просто вопрос производительности, а вопрос выживания исторических данных.

Привет! Меня зовут Максим Иванков, я развиваю школы программирования и робототехники для детей уже 9 лет. Сегодня расскажу про то, над чем работал последние 9 месяцев с перерывами — про свой собственный скрейч. Назвал я его Кубоша. Это визуальный редактор блочного программирования в стиле майнкрафта, в который я встроил задачи с автоматической проверкой и интегрировал в свою онлайн школу.

Ранее в статье: Soft Skills для тестировщика: почему «мягкие» навыки важнее «жестких» скриптов я попытался рассказать почему для тестировщика важно развивать Soft Skills, а сейчас разберемся как это реализовать на практике.

Развитие мягких навыков — не разовая акция, а постоянный процесс. Поскольку я работаю QA‑инженером, то данный материал в большей степени будет полезен для QA, но и разработчики и менеджеры и другие участники команды могут найти для себя что-то полезное.  Ниже я привел конкретные, проверяемые методы для прокачки ключевых soft skills.