Как стать автором
Обновить
100.06

Проектирование и рефакторинг *

Реорганизация кода

Сначала показывать
Порог рейтинга
Уровень сложности

Анемичная модель предметной области и логика в сервисах

Уровень сложности Средний
Время на прочтение 20 мин
Количество просмотров 1.7K

Анемичная модель предметной области (Anemic domain model) это такая модель, где сущности содержат только свойства, а бизнес-логика находится в сервисах. Ее противоположность это богатая модель предметной области (Rich domain model), где логика находится в сущностях, а cервиcы рекомендуют писать только в редких случаях.

В этой статье я хочу показать, почему логика в сервисах является более правильным подходом. Мы рассмотрим пример бизнес-требований и их реализацию с Anemic domain model.

Читать далее
Всего голосов 11: ↑9 и ↓2 +7
Комментарии 14

Новости

UML: обзор основных типов диаграмм, диаграмма объектов. Часть 3

Время на прочтение 3 мин
Количество просмотров 3.2K

Хабр, привет! В прошлых статьях про UML (Часть 1, Часть 2) мы узнали что такое язык моделирования UML и зачем он нужен, а также рассмотрели диаграмму классов и диаграмму компонентов. Сегодня я хочу продолжить тему проектирования процессов и остановиться на диаграмме объектов.

Читать далее
Всего голосов 9: ↑7 и ↓2 +5
Комментарии 2

Proof of Work и Proof of Stake для чайников

Уровень сложности Простой
Время на прочтение 6 мин
Количество просмотров 1.5K

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

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

Для достижения консенсуса в блокчейне существуют механизмы Proof of Stake и Proof of Stake. Рассмотрим их в этой статье.

Читать далее
Всего голосов 18: ↑16 и ↓2 +14
Комментарии 10

Пиррова победа Domain-Driven Design

Уровень сложности Сложный
Время на прочтение 7 мин
Количество просмотров 8.2K

TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД.

DDD вполне успешно решает поставленную задачу: дать разработчикам инструменты, которые позволят им справится (корректно реализовать и поддерживать) со сложной предметной областью. Но эта победа оказалась пирровой: инструменты, обеспечивающие корректность данных в памяти, оказались неспособны гарантировать корректность данных в БД. А что толку от изначально корректных данных в памяти, если со временем (после их сохранения в БД и последующего чтения) они перестают быть корректными? По сути, у DDD есть фатальный недостаток: DDD неизбежно приводит к нарушению целостности данных (инварианта бизнес-логики) в БД.

Читать далее
Всего голосов 36: ↑33 и ↓3 +30
Комментарии 98

Истории

Покрытие архитектуры as Code тестами

Уровень сложности Простой
Время на прочтение 16 мин
Количество просмотров 3.7K

💬 На самом деле, моя идея написания тестов на архитектуру настолько проста, легко реализуема и при этом полезна, что я до сих пор толком не понимаю, почему я не встречал материалов на эту тему, и сама тема всё ещё не используется повсеместно 🙂
Статья написана по следам моих докладов на трёх крупных ИТ-конференциях, на каждой из которых ко мне подходили архитекторы и разработчики российских бигтехов, говорили, что я очень точно попал в их боли и предложил суперпрактику, которую они теперь будут внедрять. На всех трёх конференциях я получил высшие оценки от аудитории, а на двух из них доклад был признан лучшим в своей секции. В конце статьи приведена ссылка на видео доклада с одной из конференций.
В статье я поделюсь своей идеей и OpenSource-реализацией решения для написания тестов, разберу примеры тестов на небольшой учебной микросервисной архитектуре, а также расскажу про личный опыт и профит от применения этой практики.
Для разработчиков монолита тоже есть небольшой бонус: в OpenSource-репозитории появилась реализация и примеры тестов на архитектуру модульного монолита.

Читать далее
Всего голосов 21: ↑20 и ↓1 +19
Комментарии 8

Мы пилили монолит — много нас, а он один. Полезные советы от команды Яндекс Еды

Уровень сложности Простой
Время на прочтение 14 мин
Количество просмотров 13K

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

Распилить
Всего голосов 37: ↑35 и ↓2 +33
Комментарии 34

История импортозамещения: от BluePrism к SaluteRPA

Уровень сложности Средний
Время на прочтение 7 мин
Количество просмотров 917

Привет, Хабр! Я Смолин Максим, разработчик и администратор баз данных в продуктах RPA BluePrism и SaluteRPA в Блоке Технологий Сбербанка, руководитель ИТ-направления. Мы с командой развиваем продукт SaluteRPA — роботизированная автоматизация процессов Сбербанка. Я расскажу, почему нас не устраивала платформа от зарубежного вендора, и почему мы решились на создание собственной платформы роботизации.

В 2017 году в банке начали использовать систему RPA BluePrism. На этапе MVP всё было великолепно, но потом началось много вопросов. ЦПУ (центральное процессорное устройство) сервера БД зашкаливали за 95 %, процессы тормозили и не успевали отрабатывать в нужное время, инциденты сыпались как из рога изобилия. С этого момента началась наша работа по превращению софта, рассчитанного на малый бизнес, в софт уровня предприятия с тысячами роботов. В итоге она привела к написанию собственного продукта SaluteRPA.

Архитектура RPA BluePrism достаточно проработана. Но вот реализация на уровне БД имела много замечаний с нашей стороны. Что-то мы отправляли на переделку вендору, что-то дорабатывали сами, а что-то смогли реализовать только в своём продукте.

Забегая вперёд, скажу, что внедренные нами изменения позволили преодолеть ограничение RPA BluePrism в 100 роботов на одну БД и уверенно держать нагрузку до 500 роботов на одну БД.

Читать далее
Всего голосов 6: ↑6 и ↓0 +6
Комментарии 2

Приложение викторины: внедрение Cardoteka и основные паттерны проектирования с Riverpod

Уровень сложности Сложный
Время на прочтение 32 мин
Количество просмотров 442

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

Если очень хочется создать викторину, то почему бы и да! Но на пути будет много увлекательных происшествий. Эта статья на гране сумбурного изыскания лучших паттернов проектирования. Вот что рассмотрено:

о слоях и взаимосвязях в архитектуре

формула: 2x реактивность = Riverpod + Cardoteka

особенности проектирования бизнес-логики

лучшие паттерны для работы с Cardoteka

определение репозиториев и про Trivia Api

настройка github actions для деплоя web и релиза подписанных apk 🎁

И всё это под лязг пластмассовых катан. Прошу, вы устанете, но будет весело!

Повеселиться и устать
Всего голосов 3: ↑3 и ↓0 +3
Комментарии 0

Правильный подход к модульной архитектуре

Уровень сложности Средний
Время на прочтение 8 мин
Количество просмотров 6K

Эта статья строится на двух простых идеях:

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

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

Читать далее
Всего голосов 6: ↑6 и ↓0 +6
Комментарии 3

Паттерн Aggregate Outside

Уровень сложности Средний
Время на прочтение 5 мин
Количество просмотров 5.6K

Руслан Гнатовский aka @Number55 в свой статье Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя описал известную проблему протекания бизнес-логики из агрегата, в случае если эта логика зависит от данных которые находятся вне агрегата, и предложил несколько решений этой проблемы, каждое из которых не лишено недостатков. Многие из этих недостатков были описаны в статье а также в комментариях поэтому я не буду здесь дублировать эту информацию а попытаюсь предложить решение которое этих недостатков лишено.

Читать далее
Всего голосов 25: ↑25 и ↓0 +25
Комментарии 17

GET запросы на практике: правила, принципы и примеры

Время на прочтение 14 мин
Количество просмотров 11K

Я думаю, что вы не раз уже гуглили, заглядывали в статьи, манифесты IT-гигантов о лучших практиках проектирования API. Я тоже.

Но в большинстве из них всё ограничивается описанием URL ресурса, мотивацией использовать пагинацию, сложными словами про кэширование и SSL. Это, безусловно, необходимо для общего понимания технологий, но практически не помогает, когда ты сидишь перед пустой страницей и надо начать “проектировать контракт”.

Я работаю тимлидом направления системного анализа в X5Tech и за все время развития карьеры сталкивалась с большим количеством кейсов проектирования Web систем. IT продукты в большинстве очень динамичны: постоянно изменяются требования, появляются новые, итеративно улучшается пользовательский опыт (по принципу 20% усилий на 80% результата, а остальное доделаем потом).

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

В этой статье предлагаю спроектировать контракт по шагам, и на каждом из них я расскажу про общие рекомендации из копилочки “Полезное”, а также про личные правила и практики, полученные долгим опытом работы над постоянно меняющимися ИТ-продуктами, которые помогут для “дальновидного” проектирования GET REST API.

Читать далее
Всего голосов 25: ↑23 и ↓2 +21
Комментарии 11

Челлендж по обработке миллиарда строк на Go: от 1 минуты 45 секунд до 4 секунд

Уровень сложности Средний
Время на прочтение 14 мин
Количество просмотров 19K

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

Я немного опоздал, соревнования проводились в январе. И на Java. Меня не особо интересует Java, зато давно интересует оптимизация кода на Go.

Этот челлендж был очень прост: обработать текстовый файл названий метеорологических станций и температур, и для каждой станции вывести минимальное, среднее и максимальное значение. Чтобы упростить задачу, было ещё несколько ограничений, однако я проигнорировал те, что относятся только к Java.

Читать далее
Всего голосов 65: ↑63 и ↓2 +61
Комментарии 20

Итак, вы унаследовали старую кодовую базу на C++. Что дальше?

Уровень сложности Средний
Время на прочтение 21 мин
Количество просмотров 13K

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

Теперь вы отвечаете за кодовую базу на C++. Она большая, сложная и своеобразная; достаточно слишком долго на неё посмотреть, как она начинает разваливаться разными интересными способами. Иными словами, это легаси.

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

И что делать теперь?

Не волнуйтесь, у меня такое случалось очень много раз и в разных компаниях (кто-то язвительный может спросить: а разве кодовые базы на C++ бывают какими-то другими?), выход есть, он не особо сложен и поможет вам действительно устранять баги, добавлять фичи, а то и когда-нибудь переписать её.

В этой статье я расскажу о том, что оказалось полезным для меня, и о том, чего стоит всячески избегать.
Читать дальше →
Всего голосов 68: ↑67 и ↓1 +66
Комментарии 25

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн

Валидация данных на уровне бизнес-логики приложения

Уровень сложности Средний
Время на прочтение 2 мин
Количество просмотров 3.2K

Данная статья продолжает тему статьи «Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя».

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

Подобная задача предельно типовая и поэтому должна иметь типовое решения. Далее рассматривается решение, основанное на трёхслойной архитектуре, в которой каждый слой (layer) состоит из трёх подслоёв (sublayer). Такая архитектура была описана в статье «Пример описания многослойной архитектуры, основанной на использовании наборов подслоёв и иерархии моделей данных».

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

При получении запроса функционал веб‑сервиса десериализует данные пользователя в объект типа UserDTO. В этом объекте в поле Email находится адрес электронной почты нового пользователя. Этот адрес электронной почты должен быть уникален на уровне соответствующего поля таблицы Users, в которой в базе данных хранятся данные пользователей приложения.

Читать далее
Всего голосов 8: ↑4 и ↓4 0
Комментарии 28

Как перестать переусложнять и начать жить

Уровень сложности Простой
Время на прочтение 10 мин
Количество просмотров 41K

Мое наблюдение состоит в том, что мы — разработчики и продукты, сильно переусложняем, осознанно или нет, но всякие «„Архитектурные комитеты“, „Планирования“, „Апрувы у 50 отделов“ и деплои в 2-часовые окна, простыни текста сопровождающие простейшие фичи — это просто какой‑то бич современной разработки. Умные дяди с 20 летним опытом за плечами, с невозмутимыми лицами сутки напролет на созвонах обсасывают простейшие вещи вроде замены кнопки. Что это? Следствие усложнения программного обеспечения или засилие не тех людей не на тех местах? Или следствие входа в индустрию новичков, стремящихся простое сделать сложным?

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

Читать далее
Всего голосов 71: ↑64 и ↓7 +57
Комментарии 173

Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя

Уровень сложности Средний
Время на прочтение 10 мин
Количество просмотров 7.2K

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

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

Читать далее
Всего голосов 14: ↑13 и ↓1 +12
Комментарии 95

Архитектура MVC и поддержка реактивности для jQuery

Уровень сложности Средний
Время на прочтение 15 мин
Количество просмотров 6.9K

Относительно небольшой материал по теме как мы можем организовать поддержку MVC архитектуры для средних и больших проектов со стороны Frontend разработки, вне поля современных решений.

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

Читать далее
Всего голосов 3: ↑3 и ↓0 +3
Комментарии 10

Книга «Эволюционная архитектура. Автоматизированное управление программным обеспечением. 2-е межд. изд.»

Время на прочтение 19 мин
Количество просмотров 2.8K
image Привет, Хаброжители!

Новые инструменты, фреймворки методики и парадигмы вновь и вновь меняют экосистему
разработки программного обеспечения. Непрерывный прогресс основных практик разработки
на протяжении последних пяти лет заставил искать новые пути и подходы к архитектуре, чтобы
соответствовать постоянно меняющимся требованиям пользователей. В обновленном издании
авторы Нил Форд, Ребекка Парсонс, Патрик Куа и Прамод Садаладж приводят реальные примеры, соответствующие потребностям современной разработки ПО.

«Эта книга знаменует собой важную веху, обозначающую нынешний уровень понимания проблемы. По мере того как люди начинают осознавать роль ПО в XXI веке, информация о том, как реагировать на изменения, сохраняя достигнутое, становится важнейшим навыком в области создания программного обеспечения». — Мартин Фаулер.
Читать дальше →
Всего голосов 10: ↑10 и ↓0 +10
Комментарии 8

Практический пример декомпозиции монолитного PHP приложения

Уровень сложности Средний
Время на прочтение 26 мин
Количество просмотров 6.6K

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

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

Читать далее
Всего голосов 28: ↑28 и ↓0 +28
Комментарии 6

Можно ли запустить ембедед С-проект на базе РТОС в режиме симуляции под Windows?

Уровень сложности Средний
Время на прочтение 8 мин
Количество просмотров 1.5K

Если у вас есть эмбедед(embedded) проект и он написан на С или на С++ вы можете попробовать запустить этот проект в режиме симуляции на десктопном ПК и даже под Windows, по крайней мере у нас это получилось.

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

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

Читать далее
Всего голосов 2: ↑2 и ↓0 +2
Комментарии 49

Вклад авторов