Ключове тут — в разі правильного і до поки ви уважно обробляєте строки які передаються через json

Основні недоліки роботи з даними через збережені процедури полягають у створенні додаткового «технічного» (не обумовленого бізнес вимогами) прошарку в доволі специфічному середовищі на специфічній мові програмування. В обмін на отримання mysql RPC API «з коробки», ви отримаєте наступні проблеми:
— версіонування. У випадку збережених процедур не достатньо зробити git pull + compile + deploy. Потрібно робити окремі скрипти на кожну процедуру для оновлення, надання прав і т.і. Дуже важко робити canary deploy, тому що на відміну від прикладних серверів, сервер бази один (міграція данних — процедура дуже коштовна), а функціоналу підтримки різних версій та міграцій «з коробки» нема. Тому у збережених процедур свій життєвий цикл, і дуже важко використовувати той самий цикл розробки та розгортання на основі системи контролю версій як з основним кодом.
— SQL injection over JSON :) Збережені процедури полюбляють DBA, яким база надає стандартні методи влади — дозволити/заборонити. Можливість обходу таких обмежень в коді процедури, в купі з не самими ефективними функціями санітізації, роблять можливість взлому даних більш імовірною.
— міграція на нову версію мови хранимих процедур дуже коштовна, тому що потребує оновлення серверу бази даних. Ніякого смузі, один COBOL SQL! І це не в окремому (мікро/web/SOA)-сервісі на кшталт «розрахунок сніданку таргана _ спитати Васю що на пенсії _ тел 467544654», а в базовому прошарку вашого додатку. «Всім джуніорам потрібно негайно вивчити мову програмування MySQL процедур версії 4.3.67»

«К концу 18-го века люди инвестировавшие деньги в работорговлю получали 6% годовых. Любой финансовый консультант вам скажет, что это вполне приличный доход»

Учитывая, что в IT продают длительный сервис, давайте проведем аналогию с рестораном, парикмахером, семейным врачем и автосервисом.

Чудовий опис особистого досвіду!

А що не так з WAL, RCU, Sagas, etc.
Нема «нормального» рішення, є рішення з обумовленими вимогами та обмеженнями до atomicity, consistency, linearizability, isolation

Яке щастя що можливо використовувати DI без інтерфейсів і тестувати бібліотеки в цілому.
Дивіться яке неподобство github.com/...​oreLib/System/Collections
Негайно створюйте issue і вимагайте негайного відокремлення інтерфейсів в окрему сбірку!

... А замовник помер та залишив спадок на підтримання проекту без будь-яких функціональних змін у майбутньому.

Сказ о харкождених энумах.
Я теж намагався створити довідникову таблицю для таких «потенційнолегкоконфігуруємих» значень. Навіть э такий архітектурний псевдо Data/driven approach на деяких проектах.
А потім побачив проект, де такі данні не те що переведені в энуми, а ще й двідчі захардкоджені — на серверах, та в кліентах.
Щелепу підіймав довго, довго бив себе по руках щоб все не «переробитиякпотрібно!», а потім закохався!
От же ж програмісти хитрі, не бажають мабуть щоб їх якийсь DBA підсидів!
А на справді, ці дані э частиною контракту. І зміна в даних вимагає перегляду пов‘язанного коду, можливо зміни версій або розширенню контрактів, можливо зміни клієнтських додатків

Намагайтесь використовувати стандартний projection ef і тоді «ваші волосся будуть завжди шовковисті»...
Це той який LINQ-to-XML, EF6, EF core, EF dotConnect, EF MySuperImplementation?
Дуже змістовна та вичерпна порада!

DTO?
Це той що мінімізує число викликів зв‘язанних сервісів на фасадах видалених інтерфейсів?
Тоді так, не гоже його з класами бази данних міксувати.
(Ну може окрім випадків mongo, couch, cache та інших DB, — застарий я вже, може й помиляюсь)

Дивiться уважнiше: «инжиниринг, дизайн, продукт-менеджмент + business advisory и найм на стороне клиента», «интеграция в бизнес клиента, умение закрывать существующую боль клиента, проактивность и collective leadership».
Центр тI soft skills, якi не «вчаться» та якi не тотожнi просто додаванню UX та BA специалистiв. Це тi навички, якi в вас як в окремому контракторI буде шукати рекрутер дивлячись як ви вирiшували виклики на проектах до цього часу.

Разница как «сделайте мне Гугл» на фрилансе и «сделайте мне Яндекс» как предложения Михаилу Парахину и Глебу Абовскому

Delloite продаёт в первую очередь свой бизнес опыт и кейсы по работе с сотнями клиентов из твоей индустрии. «Воруй как художник» :)

Вы реально крутые

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

Зубы от страха поломает :)
Что дальше — каждая компания решает сама и несёт ответственность за свои решения с учётом состояния рынка.

Да у вас прямо софтверный бутик :)
По факту подсматривания — а как страдают бедные сотрудники коворкингов. Так может нужно просто рабочую культуру соблюдать?

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

А ещё он может описать предлагаемую архитектуру используя лучшие практики AWS и Azure, предложить своё видение развития продукта и технологии в разрезе пары лет, нарисовать от руки или в редакторе несколько итераций прототипа опираясь на свой опыт и знание технологии и не привлекая выделенного UX специалиста, может настроить пайплайн для деплоя и тестирования. И таких людей на рынке много, конкуренция за рабочие места высокая.