Наш Альфа-Банк прекрасен. Мы его очень любим, но он такой большой-большой, разнообразный и сложный. Думаю, никого не удивил :) Наш ИТ-ландшафт содержит великое множество всякой «флоры и фауны», с которой необходимо считаться. То тут, то там, из глубоких Enterprise джунглей нам улыбаются и игриво подмигивают орды легаси-систем, каждая из которых живет своей собственной жизнью и поддерживается разными командами. Например, HR-вопросы — это SAP HCM, со своими потоками и фронтами, написанными на SAP UI5, Fiori, вопросы учета — SAP ERP, а есть ещё IBM Lotus Notes, системы документооборота и пр., и пр.

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

Всем привет, меня зовут Олег Кругляков, я руководитель направления в одной из команд клиентского пути сотрудника Alfa People. В статье хочу поделиться опытом создания сервиса, который объединяет все эти заявки в одном месте без «беготни» по разным системам. При всем при этом, он весело работает в браузере и весело работает в мобильном приложении, нордически выдерживая единый дизайн. Ну, приятно, чего греха таить ?

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

"Отдайте этот функционал в другую системы - он относится к ним" - ворчал мой собеседник. Ему с пылом отвечали: "Так быть не должно. Мы сами должны его сделать!" Спор грозил затянуться до вечера. Ни одна из сторон не могла привести ни одного настоящего аргумента, почему новый функционал нужно поместить в ту или иную автоматизированную систему.

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

Но методика на самом деле есть, и весьма неплохая. Называется она Предметно Ориентированным Дизайном (Domain Driven Design, DDD). С помощью DDD деление большой системы на (микро)сервисы становится простым и понятным.

Привет! Продолжим тему гексагональной архитектуры и DDD, первый пост — здесь. 

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

Гексагональная архитектура

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

Я приведу основные мысли.

Гексагональная архитектура имеет три фундаментальных блока:

В предыдущих двух постах (раз, два) мы разобрали, какие проблемы решает гексагональная архитектура и как выглядит архитектура у нас в проекте. Теперь давайте посмотрим, как обстоят дела с кодом, который должен поддерживать описанную архитектуру.

Как я уже писал, мы взяли из DDD тактические шаблоны.

Если какое-то понятие предметной области является уникальным и отличным от всех других объектов в системе, то для его моделирования используется сущность.

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

Для этого используются уникальные идентификаторы.

Сущность в коде нашего проекта должна иметь:

1. Общие сведения.
2. Увеличиваем потребление памяти вдвое.
3. Увеличиваем потребление памяти втрое.
4. Ещё раз увеличиваем потребление памяти на ровном месте.
5. Заключение.

Микросервисная архитектура помогает строить гибкие и масштабируемые приложения. Однако в случае бессистемного использования этого подхода вы довольно быстро столкнётесь с разочарованием и неконтролируемыми сложностями. Избежать проблем помогает Domain-Driven Design (DDD) — предметно-ориентированное проектирование. В статье расскажем о принципах его работы, а также разберём основы стратегических паттернов в Golang. 

Как перенести обработку электронных писем в отдельный процесс, чтобы он не блокировал исходный веб-запрос? Именно это мы и рассмотрим в данной статье, в частности, всевозможные способы решения данной проблемы на PHP, используя новую инфраструктуру (или без нее).

Понимание того, чем является архитектура и способность оценить её качество - разные вещи. Зачастую она воспринимается, как нечто неотделимое от ПО, присущее ему. Как следствие, зачастую, сама роль и ее задачи ускользают от разработчика.

В этой проблеме поможет разобраться Роман Хаимов. Он занимается разработкой ПО в практике Frontend “Рексофт”, компании, которая более 30 лет занимается разработкой ПО на заказ для российских и международных компаний. Сегодня Роман расскажет про главную задачу (или роль) любого структурного элемента в приложении. Вместе с ним мы посмотрим на простых примерах, на что влияет архитектура проекта, а также поймем, что может изменить ситуацию к лучшему.

Рекомендую присмотреться к списку, если ваш проект вырос или планирует рост, написанный на любом интерпретируемом языке (php/ruby/python) на нескольких серверах с обычным стеком (веб-сервер/сервер приложений, субд, redis/memcahed, rabbitmq, ...).

В качестве подопытного для оптимизации был взят PHP backend - все нижеперечисленные приёмы были опробованы и применены. Наш проект почему-то задыхался на казалось бы неплохом железе и к тому же не утилизировал выданные ему аппаратные ресурсы.

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

Привет, друзья!

Представляю вашему вниманию перевод первой части серии статей, посвященных паттернам проектирования в TypeScript.

Спасибо Денису Улесову за помощь в переводе материала.

Паттерны (или шаблоны) проектирования (design patterns) описывают типичные способы решения часто встречающихся проблем при проектировании программ.

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

Методология Twelve-Factor App (Приложение двенадцати факторов), которую создал сооснователь платформы Heroku Адам Уиггинс, направлена на разработку SaaS-приложений. Документ, описывающий эту методологию, включает в себя множество идей, применение которых сделало использование и, я уверен, создание платформы Heroku, увлекательным и благодарным трудом.

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

Как, со времени представления методологии Twelve-Factor App в 2011 году, эволюционировали принципы, положенные в её основу? Чему они могут нас научить сегодня? Как эти принципы изменили положение дел в недавнем прошлом?

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

Одним из таких инструментов, которые хорошо себя зарекомендовали в моей работе по проектированию интерфейсов, стало «Задание на проектирование».

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

Меня зовут Александр Донсков и я архитектор в компании REG.RU. Сегодня я расскажу о том, что такое Event Storming и что будет, если запереть 10 человек в одной комнате (в том числе виртуальной). Цель статьи не столько в том, чтобы рассказать, как это работает, сколько показать действенность подхода на реальных кейсах.

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

Меня зовут Александр Пряхин, я TechUnit Lead в Авито. В IT работаю уже 14 лет. Из них 8 лет руковожу командами. Параллельно с этим преподаю и менторю. Сегодня разберём, как готовить демонов на PHP — от А до Я, и почему это актуально.

Количество классов в реализации даже небольшой программы на один человеко-месяц исчисляется десятками. В средних программах на несколько человеко-лет счёт идёт уже на тысячи. А человек может одновременно оперировать 7-ю +/- 2 объектами. Поэтому все нетривиальные программы требуют декомпозиции своей реализации на более крупные блоки, чем классы - я буду называть такие блоки пакетами.

Сейчас наиболее распространены два основных подхода к декомпозиции систем: пакетирование по слоям и техническим аспектам (далее просто "по слоям" для краткости) и пакетирование на основе предметной области (представленное группой вариантов: пакетирование по фичам, пакетирование по компонентам, ограниченные контексты и пакетирование по агрегатам из предметно-ориентированного дизайна (DDD))

Однако ни один из этих подходов мне не подошёл в полной мере и я изобрёл…​ объектно-ориентированный подход к декомпозиции систем. Точнее, я изобрёл простую методику выполнения декомпозиции, а потом понял, что на выходе она даёт штуки обладающие свойствами объекта.

Но обо всём по порядку - сначала я рассмотрю критерии оценки подходов, распространённые подходы и почему они мне не подошли. А закончу пост представлением методики выполнения объектно-ориентированной декомпозиции.