Динамический высокоуровневый язык программирования
В первой статье мы выделили область применения обозначенных практик, для каких проектов их можно применять, а для каких не следует.
В данной статье я хотел бы сделать краткий обзор основных принципов DDD, а также поделиться личным опытом их применения. Более подробно будет рассказано о коммуникационных и структурных подходах с примерами их реализации.
В следующих статья распишу возможные комбинации применяемых паттернов проектирования с учетом их имплементации, и в конечном итоге приведу пример конкретной реализации одного небольшого микросервиса.
Я хотел бы рассказать об опыте применения практик DDD к существующему Ruby on Rails проекту. Изначально, мы имели монолит, который писался 10 лет. Основная трудность проекта была в достаточно сложных процессах, и высокой связанности. Нам удалось не только декомпозировать приложение на отдельные сервисы, но и существенно повысить читаемость кода, сделать описываемые процессы прозрачными.
Решение задач в рамках системы стало предсказуемым, мы перестали работать с черным ящиком, и в конечном итоге система сама стала подсказывать нам решения.
Для облегчения как восприятия, так и написания, рассказ о применяемых подходах будет представлен в виде цикла статей. Данный подход не является "серебряной пулей", поэтому я бы хотел выделить прежде всего тот сегмент проектов, которым это решение сможет подойти. Далее, я более подробно расскажу о DDD методологии и микросервисной реализации данного паттерна, распишу возможные комбинации применяемых паттернов с учетом их имплементации, и в конечном итоге приведу пример конкретной реализации одного небольшого сервиса.
Как вы попали в мир программирования и Ruby?
В началье статьи хочу сразу заметить, что я не претендую на новизну, а только хочу поделиться/напомнить о такой возможности как IoC DI.
Также у меня почти нет опыта написания статей, это моя первая. Я старался как мог, если что не судите строго.
Большая часть проектов на Rails, с которыми я сталкивался, имеют одну большую проблему. Они либо не имеют тестов вовсе, либо их тесты проверяют какую-то незначительную часть, при этом качество этих тестов оставляет желать лучшего.
Основная причина этого заключается в том, что разработчик просто не знает как можно написать код так, что бы в unit-тестах тестировать только написанный им код, а не тестировать код, который, допустим, содержится в каком-то ином сервисном объекте или библиотеке.
Далее в голове программиста складывается логичная цепочка, а зачем мне вообще выносить код бизнес логики в другой слой, я же тут всего пару строк добавлю и все будет соответствовать требованиям заказчика.
И это очень плохо, потому что модульное тестирование теряет устойчивость к рефакторингу, управлять изменениями в таком коде становится тяжело. Энтропия постепенно растет. А если вы уже боитесь рефакторить свой код, дела очень плохи.
Для решения в подобных задач в мире Java уже давно существует ряд библиотек и нет особого смысла изобретать велосипед, хотя, надо заметить, что эти решения весьма громоздкие и не всегда есть причина их использовать. Рубисты видимо как-то иначе решают подобные задачи, но я, честно говоря, так и не понял как. По этому я решил поделиться как это решил сделать я.
Что бы далеко не ходить, сразу определимся с терминами.
Взято с вики. В языке программирования Ruby с инкапсуляцией вроде как всё хорошо. С сокрытием на первый взгляд тоже, нам доступны локальные переменные, переменные инстансов, разные уровни доступа к методам (public, protected, private). Но иногда этого может не хватать.
Это история о том, почему вы никогда не должны замалчивать ошибки, когда вы внутри транзакции в базе данных. Узнайте, о том как правильно использовать транзакции и что делать, когда их использовать — не вариант. Спойлер: речь пойдёт об advisory locks в PostgreSQL!
Я работал над проектом, в котором пользователи могут импортировать большое количество тяжёлых сущностей (назовём их товарами — products) из внешнего сервиса в наше приложение. К каждому товару при этом загружается ещё больше разнообразных связанных с ним данных с внешних API. Нередка ситуация, когда пользователю нужно загрузить сотни товаров вместе со всеми-всеми зависимостями, в итоге импорт одного товара занимает ощутимое время (30-60 секунд), а весь процесс может порядочно так затянуться. Пользователю может надоесть ждать результата и у него есть право нажать кнопку «Отмена» в любой момент и приложение должно быть полезным с тем количеством товаров, которые удалось загрузить к этому моменту.