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

Эта статья является переводом материала «Mapper Contexts & Supercontexts: Decoupling Domain-Specific and Domain-Generic Bounded Contexts».

Вы создаете новую систему, и два члена вашей команды предлагают альтернативные архитектуры для отправки уведомлений. Какая из них правильная?

Первый разработчик предлагает модель push: ограниченный контекст должен дать указание Notifications отправить уведомление. Notifications должен просто подчиняться командам и отправлять указанные уведомления.

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

Как бы вы спроектировали решение? Что еще более важно, как бы вы приняли это решение в команде? Как вы будете разрабатывать наиболее эффективную архитектуру, которая поддерживает краткосрочные цели и долгосрочное развитие?

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

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

1 сентября 2021 года ФНС перестала обновлять свой адресный справочник в формате ФИАС. Относительно новый ГАР внезапно стал единственным государственным адресный реестром, доступным общественности. Рассказываем, что из себя представляет новый справочник и чем он отличается от ФИАС.

Уже более 17 лет я, тем или иным образом, занимаюсь внедрением и разработкой программного обеспечения. Значительная часть моих решений предназначена  для моих клиентов в России и  за рубежом. Все они связаны с вопросами автоматизации и оптимизации работы компаний. Одной из важных проблем при таком сотрудничестве всегда оказывается вопрос,  с чего начать и как понять, из чего состоит предприятие.

Я перепробовал разные способы, и почти всегда при этом работал по процессной модели. Мне ставили определенные задачи, я описывал один, два, три процесса, и, в принципе, всех это устраивало. Но меня не покидала мысль о том, что есть всё-таки какая-то универсальная модель предприятия, которую можно использовать из раза в раз. И если для меня она со временем стала интуитивно понятной, то для людей, которые только начинают свою деятельность в этой сфере или не сталкиваются постоянно с автоматизацией, а потому не имеют такого опыта, как я, конечно, возникает множество вопросов, Большинство из них связаны с тем, с чего начинать работу, как и что в каждом из случаев внедрять, и вообще, как строить свое сотрудничество с клиентами и зарабатывать в этой сфере. 

В связи с этим я решил описать, то есть создать некую почти универсальную модель. Я к ней шёл уже, наверное, лет десять.Конечно, я не занимался ее разработкой все это время. Но уже  десять лет назад у меня были первые, скажем так, черновики такой модели.

Сегодня, в субботу 26 февраля, на Сколковской Школе Синтеза Цифровых Схем Михаил Коробков проводит занятие по технологиям функциональной верификации: constrain solvers, cover bins и concurrent assertions. Примеры, которые мы подготовили для школы, вращаются вокруг протокола AXI для систем на кристалле, вопросы про который спрашивают например на интервью в хардверное отделение компании Meta и другие.

На предыдущих занятиях школы мы изучали в основном аспект проектирования на языке описания аппаратуры Verilog. Но как участники уже успели заметить, Verilog — это не только язык для описания и синтеза схем, но и язык программирования для написания тестов. В некоторых компаниях на каждого инженера, который пишет код на верилоге на уровне регистровых передач, приходится два или три инженера, которые пишут код для верификации.

Суть деятельности Verification Engineer заключается в создание фреймворков, которые тестируют хардверные дизайны на прочность, посылая к ним псевдослучайные транзакции и учитывая покрытие интересных сценариев (functional coverage). Базовые элементы этих технологий должен знать и хороший RTL Design Engineer.

Приглашаем присоединяться к трансляции занятия на канале школы в YouTube, в субботу 26 февраля с 12.00 до 15.00:

Привет, меня зовут Евгений, и я никогда не был программистом — написание кода вызывало у меня чуть ли не смертельную скуку. Конечно, за двадцатилетнюю карьеру приходилось писать скрипты на PowerShell, Python и т. д., но о серьёзной разработке речи не было. Тем не менее моя профессиональная деятельность не ограничивалась системным администрированием. В какой-то момент я познакомился с Microsoft SharePoint — технологией, которая и определила вектор моего развития как IT-специалиста.

SharePoint — это огромный конструктор со множеством деталей, из которых можно собрать практически что угодно — от корпоративного новостного портала до mission critical системы. В нём собраны все необходимые службы и приложения для работы с контентом. Кроме того, SharePoint позволяет создавать несложные сайты с уникальным дизайном и лендинги. А вот что касается автоматизации бизнес-процессов, то тут администраторы быстро понимают, что есть два пути: либо разрабатывать фичи самостоятельно (или обращаться к программистам), либо использовать внешние (по отношению к SharePoint) решения. Я пошёл по второму пути — и в итоге, пришел к no-code/low-code (NC/LC) — решениям, позволяющим создавать приложения практически без использования сложного кода. Это подкупает: можно быстро разрабатывать сложные решения, не прибегая к программированию. Но всё оказалось не так просто, и сегодня я расскажу, почему NС/LC-решения не взлетели в Ozon.

Если вы собрались плотно погрузиться в тему Doman Driven Design (DDD), о том как его применять, как использовать, для чего он нужен, и как с ним связаны Command and Query Responsibility Segregation (CQRS), Event Sourcing и другие термины из мира DDD то можно воспользоваться планом обучения, который последовательно погрузит вас в эти темы и поможет сориентироваться. Часть информации на русском, часть на английском языке, так как русскоязычных аналогов я не смог найти.

Лекции по курсу «Управление Техническими Системами» читает Козлов Олег Степанович на кафедре «Ядерные реакторы и энергетические установки» факультета «Энергомашиностроения» МГТУ им. Н.Э. Баумана. За что ему огромная благодарность!

Данные лекции готовятся к публикации в виде книги, а поскольку здесь есть специалисты по ТАУ, студенты и просто интересующиеся предметом, то любая критика приветствуется. В предыдущих сериях:

1. Введение в теорию автоматического управления.
2. Математическое описание систем автоматического управления 2.1 — 2.3, 2.3 — 2.8, 2.9 — 2.13.
3. ЧАСТОТНЫЕ ХАРАКТЕРИСТИКИ ЗВЕНЬЕВ И СИСТЕМ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ РЕГУЛИРОВАНИЯ.
3.1. Амплитудно-фазовая частотная характеристика: годограф, АФЧХ, ЛАХ, ФЧХ.
3.2. Типовые звенья систем автоматического управления регулирования. Классификация типовых звеньев. Простейшие типовые звенья.
3.3. Апериодическое звено 1–го порядка инерционное звено. На примере входной камеры ядерного реактора. 3.4. Апериодическое звено 2-го порядка. 
3.5. Колебательное звено. 3.6. Инерционно-дифференцирующее звено. 
3.7. Форсирующее звено.  3.8. Инерционно-интегрирующее звено (интегрирующее звено с замедлением). 3.9. Изодромное звено (изодром). 
3.10 Минимально-фазовые и не минимально-фазовые звенья.

Заключительная статья из раздела 3 Частотные характеристики звеньев и система автоматического регулирования.

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

Дисклеймер: в тексте нет основных понятий и определений из теории диффузионного приближения ядерного реактора.

Меня зовут Сергей Марков, я системный аналитик бэковой части в Академии Инвестиций Тинькофф. 

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

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

Возможен ли выход из этого жизненного процесса бега в колеснице?

Применим практику анализа бизнес - процесса к жизненному циклу развития человека.

Больше 8 лет я использую Impact Map для аналитики IT-продуктов. Я довольно активно делился знаниями об этом подходе: писал статьи, выступал на конференциях с докладами и мастер-классами, рассказывал студентам в университетах и интернам в компании. Слушатели и участники мастер-классов легко улавливают, как создавать и использовать Impact Map, т.е. с теорией нет проблем. Тем не менее, я вижу большие затруднения с применением этого подхода в реальной практике, когда нужно придумать и описать идеи для сложного IT-продукта.

В этой статье я сделаю попытку объснить, каким образом формулируются идеи, которые являются самой сложной и самой ценной частью Impact Map, а также поделюсь своим видением, как наиболее эффективно воспринимать каждую из частей Impact Map.

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

Общепринятой практикой в индустрии является использование тест кейсов в качестве основы для автоматизации тестирования. QA инженеры разрабатывают их на основе user stories в рамках обычного тестирования, а затем автоматизируют эти тесты. С каждой итерацией тестируется больше историй, автоматизируется больше тестовых случаев, и набор автоматических тестов становится всё больше. Руководители продвигают такие метрики, как, например, «процент покрытия» и хвалят команды с высокими показателями. Некоторые компании даже специально нанимают «инженеров по автоматизации», чья единственная работа состоит в том, чтобы брать тест кейсы и автоматизировать их.

К сожалению, автоматизация тест кейсов и навязывание «процента покрытия» — это антипаттерн обеспечения качества, который неизбежно приводит к раздутым и сложным в обслуживании наборам тестов, которые приносят мало пользы. Хотя автоматизация имеет решающее значение для agile delivery, этот чрезмерно упрощенный подход «фабрики автоматизации» не является хорошим способом автоматизации тестирования.

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

Издержки и преимущества автоматизации тестирования

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

Мы живем в сложное время, когда доллар обесценивается, цены на акции скачут, и даже у Газпрома мечты не сбываются, а наоборот – сложности с сертификацией Северного потока-2. И за окном не май месяц, а вовсе даже серый февраль. В этот момент на первое место выходят вечные ценности: водка, секс, и  рок’н’ролл. А для секса желательно конечно, горячая вода. 

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

Данная статья – продолжение примера из лекции про изoдромное звено. 

Всем привет.

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

Привет! Я тимлид команды «Добро» в «Сравни.ру», мы занимаемся разработкой сервиса по подбору кредитных продуктов. 

Сервис, над которым мы работаем, помогает нашим клиентам подобрать кредитные продукты с высокой степенью одобрения. Для этого мы придумали алгоритм, который аккумулирует необходимый объем данных, обрабатывает их и подбирает кредитные продукты от банков, которые с высокой долей вероятности одобрят заявку конкретного пользователя. Нетипичное название команды («Добро») произошло от слова «одобрение». 

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

Бизнес-процесс – это алгоритм действия, последовательность действий сотрудников при создании товаров, работ, услуг. Многие компании заключают договора с гражданами на оказание разного вида работ или услуг. Берут в сети готовую болванку и заключают договор, который не учитывает специфику данного вида договора. Рассмотрим простой бизнес-процесс заключения договора оказания услуг с физическим лицом, который является исполнителем, с применением нотации BPMN.

DDD — одна из моих основных рабочих методологий, я применяю её больше пяти лет. Хотя она довольна сложная, в том числе потому что это верхнеуровневый набор практик. DDD - это не фреймворк, когда нет опыта, его немного сложно применять. Тем не менее мы переводили на DDD работающие проекты, запускали с помощью нее новые — и у нас сложились некоторые практики и подходы.

Хотелось бы рассказать про те, что доказали у нас свою эффективность. Сегодня это будет стратегическое верхнеуровневое проектирование — о том, как разрабатывать программы с точки зрения моделей и требований. А в следующей части я расскажу про практики для работы с кодом и архитектурой, то есть более приближенные к разработке. Надеюсь, что вы сможете ими воспользоваться, а если вы еще не используете DDD у себя в проектах, то попробуете.

В России разработана система видеоаналитики для корпоративных автопарков, которая основана на технологии компьютерного зрения. Сервис объединит в себе функции спутникового мониторинга транспорта и автономного цифрового видеорегистратора c возможностью видеоаналитики. Система сможет распознавать опасные действия водителя (небезопасные маневры, резкие торможения, курение, засыпание). Видеоаналитика станет особенно актуальной в условиях пандемии, поскольку, сможет решать важные задачи.

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

Чтобы всегда радовать пользователей, сервис Dropbox должен быть надежным и отзывчивым. С самого начала нам, как компании, приходилось масштабироваться. Сегодня нашими услугами пользуются более 700 миллионов зарегистрированных пользователей со всех уголков планеты. В общей сложности они ежесекундно генерируют минимум 300 тыс. запросов. Увы, системы, отлично подходившие для стартапа, перестали справляться с возросшей нагрузкой. Возникла насущная потребность разработать новую модель для внутренних систем и, конечно, придумать способ перехода на нее без риска угробить основной продукт в процессе.

В этой статье мы расскажем, как и почему разработали и развернули Atlas — платформу, реализующую основные преимущества сервис-ориентированной архитектуры (SOA) и при этом минимизирующую типичные издержки, связанные с владением сервисом.

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

Сегодня хочу поделиться с вами своим опытом по использованию тех или иных инструментов в своей работе.