В современной микросервисной разработке очень популярна чистая архитектура (она же луковая). Этот подход ясно отвечает на много архитектурных вопросов, а также хорошо подходит для сервисов с небольшой кодовой базой. Другая приятная особенность чистой архитектуры состоит в том, что она отлично сочетается с Domain Driven Development - они отлично дополняют друг друга.

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

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

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

Дисклеймер: данная статья не пытается открыть Америку или сделать прорыв в науке. Это просто набор архитектурных решений, которые я считаю удачными, и которыми я хочу поделиться с сообществом. За подробностями приглашаю под кат, а также буду рад обсудить в комментариях.

..  »

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

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

Что вообще такое - “путь языка Х”?

Во многих программерских сообществах развивается некоторое чутье на то, соответствует ли код или решение “пути” этого языка. Сложно сказать, почему и как это возникло, но сегодня это довольно распространено. Причем, по моим наблюдениям, чем дальше этот язык от “cutting edge” технологического мира, тем меньше в нем разногласий по этому поводу.

За последние пару месяцев у меня было много интересных событий - новая работа, всероссийский хакатон, подготовка к конференциям и т.п. И мне довелось активно поиспользовать кодогенерацию в нескольких разных контекстах. Если вкратце - мне понравилось.

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

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

Частенько в дискуссиях на тему работы я встречаю тезисы о том, как плохо работать в том или ином проекте/компании/отрасли и т.д. И несмотря на то, что в отечественном IT в целом очень распространено нытье, многое из обсуждаемого действительно имеет место в реальности. Однако, спустя годы разработки, смены проектов, компаний и даже стека технологий, у меня выработалось понимание проблемы и ее решения с другого ракурса. Об этом и поговорим.

На своем карьерном пути я повстречал большое количество различных проектов, компаний, отраслей и людей. Я далеко не сразу пришел в IT: я начинал продавцом книг (да, да, те самые, что звонят в дверь и впаривают какую-то лютую энциклопедию), раздавал листовки, работал в поддержке сотового оператора, официантом в кафе (двух), копирайтером, автором заказных статей на хабре и админом в микроконторе. Да и в IT мой путь был интересным - я поработал пентестером, программистом на заводе, фрилансером, переходил из одного стека в другой (где общим был только SQL). Это был очень интересный опыт, и я не жалею о том, что не просидел все эти годы в одной области, где, вероятно, добился бы большего, чем имею сейчас. Однако взамен я увидел многое и понял особенности работы локального и глобального рынка IT, разные подходы к управлению людьми, ресурсами и проектами, а также научился воспринимать вещи с различных сторон.

Большинство IT специалистов в качестве одного из ключевых инструментов работы используют текстовые редакторы. А если говорить о разработчиках, то это основной инструмент, а зачастую и единственный.

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

IDE (integrated development environment) существуют очень долгое время - первые продукты такого рода появились почти полвека назад. Современные IDE выполняют огромное количество функций - от подсветки кода и предупреждений об ошибках, до выполнения развертывания на кластер облачных систем и управления базами данных (да и еще много чего, наверное - о чем ни подумаешь - это уже поставляется в виде плагина к Eclipse).

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

Подготовка

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

Разработка программ в SAP экосистеме отличается от других областей программирования набором определенных особенностей, в ту или иную сторону меняющих повседневную рутину программиста. Одна из них - собственно место ABAP разработчика в мире SAP системы, его компетенции и ответственности, взаимоотношение с другими уровнями цепочки, доставляющей готовый продукт клиенту.

Дисклеймер: если вы работаете в SAP SE, SAP Labs или дочерей компании, это не про вас. Частично

У программиста, ведущего разработку на языке ABAP, существует набор обстоятельств, некоторые “но”, которые усложняют или, по крайней мере, делают более запутанной ежедневную деятельность. Я бы назвал эти “но” бременем ABAP разработчика, которое он вынужден нести, особенно если сравнивать с другими популярными сегодня направлениями разработки, как веб бэкенд или фронтенд, энтерпрайз разработка на популярных языках вроде Java, или мобильные приложения. Немного иначе дела обстоят в игрострое, в железе и встроенных системах, в хайлоаде, но я не буду рассматривать их в сравнении, потому что считаю их достаточно специфическими областями с точки зрения общих практик.

В настоящее время все большее распространение получают системы на основе S/4, одной из ключевых особенностей которых является основанная на CDS View виртуальная модель данных, на которой построена концепция “Code Push Down”.

Концепция виртуальных моделей заключается в том, что поверх таблиц БД строится древовидная иерархия CDS View, описывающих модели данных различного свойства с различными назначениями. В этой заметке я скажу пару слов про то, какие виды CDS View бывают в иерархии, и как правильно такие иерархии строить.