Реализация паттерна saga на C#

Предисловие переводчика: Уже не помню, что сподвигло меня заинтересоваться этим паттерном, скорее всего в какой-то момент мне пришлось столкнуться с javascript библиотекой redux-saga. Знакомство началось с описания паттерна от Bernd Rücker и прекрасной презентации Caitie McCaffrey. После ознакомления с этими материалами у меня всё ещё оставались вопросы. Очень хотелось увидеть этот код “в живую” в виде какого либо PoC-a.

Вашему вниманию представлена статья Clemens Vasters-a, которая поможет разобраться уже в деталях с конкретной реализацией.

Работа с ветками

Данный текст явлется переводом. Оригинал по ссылке

Если вы не знакомы с ветвлением и слиянием веток, предлагаю вам отличную HOWTO Control Source Eric Sink’s. Я предпочитаю модель бранчевания “релизная ветка” (примечание переводчика: подходы к ветвлению указанные по ссылкам немного устарели. По-моему, стоит уделить внимание более современных подходам git-flow, github-flow и gitlab-flow, но понимание сути возможных проблем при миграции изменений думаю может быть полезно).

При подходе “Релизная ветка” вся новая работа происходит в trunk ветке репозитория. Как только продукт приближается к релизу, изменения схемы становятся более редкими и фризятся новые правки. В этот момент, команда создает ветку для релиза. Разработка нового функционала продолжается в транке с изменениями в схеме и всего остального кода. В ветку отправляются только фиксы ошибок. После релиза команда объединяет исправления с ветки в trunk.

Вьюшки, хранимые процедуры и прочее

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

Но сначала…

На самом деле я уже не использую триггеры на протяжении нескольких лет. Это не означает, что триггеры бесполезны, но я, как правило, уклоняюсь от их использования. Jon Galloway опубликовал хороший пример того, что можно сделать с триггерами. Во-вторых, мне мусолят глаза хранимые процедуры. Я пришел из WinDNA идеологической школы, в которой вышеупомянутые хранимые процедуры должны использоваться все время. Сегодня я представляю хранимые процедуры в качестве API слоя для базы данных. Это хорошо, если вам нужен слой API на уровне базы данных, но я знаю множество приложений несущих накладные расходы на создание и поддержание этого слоя API в котором они не нуждаются. В этих приложениях хранимые процедуры часто приносят больше усложнений, чем пользы.