Сергей Соловьев

Если это нативный C++ - нет. В нем нет такого синтаксиса.
Если это CLI/C++ (яп для .net), то да

Чистая архитектура - это просто идея, а не готовая архитектура. Гексагональная - частный случай чистой.
В блоге Роберта Мартина первыми строками идет:

Over the last several years we’ve seen a whole range of ideas regarding the architecture of systems. These include:

Hexagonal Architecture (a.k.a. Ports and Adapters) by Alistair Cockburn and adopted by Steve Freeman, and Nat Pryce in their wonderful book Growing Object Oriented Software
Onion Architecture by Jeffrey Palermo
Screaming Architecture from a blog of mine last year
DCI from James Coplien, and Trygve Reenskaug.
BCE by Ivar Jacobson from his book Object Oriented Software Engineering: A Use-Case Driven Approach

SELECT * FROM todos GROUP BY user_id, completed;

https://jmeter.apache.org/

Потому что нельзя передавать название таблицы в качестве параметра - Оно должно быть указано явно и прямо, а параметризация нужна для ПАРАМЕТРОВ.

Либо переделывай, либо вот тут вроде есть решение

В приложении, которое использует Dependency Injection можно выделить 2 "области":
- Composition Root
- Остальное приложение

Composition Root - это место в котором собираются все зависимости воедино. О всех реализациях зависимостей должен знать только он.
Остальное приложение - это (тафтология) все остальное приложение. Они используют только интерфейсы и другие абстрации.

Обычно Composition Root - это входная точка приложения. В нем создается эта самая ServiceFactoryImpl (стандартные реализации, из конфигурации могут быть прочитаны флаги, создан в зависимости от платформы и т.д.), а затем как интерфейс IServiceFactory, передается в остальные места.

Т.е. в коде это будет как-то так

#include <IServiceFactory.h>

class Sample {
private:
    IServiceFactory _factory;
public:
    Sample(IServiceFactory factory): _factory(factory) { }
    DoSomething() { 
        auto service = _factory.CreateService();
        service.MakeStuff();
    }
}

int main() {
    auto factory = ServiceFactoryImpl(); // Читаем конфигурацию, параметры ОС и др.
    auto sample = Sample(factory);
    sample.DoSomething();
}

тебе просто нужно удалить контейнер, которому примаунчен этот вольюм.
пока контейнер ОСТАНОВЛЕН все ресурсы за ним еще сохраняются

Когда запускаешь команду сборки, просто пропускай этап тестов - gradle build -x test

1) Что будет с запросом UPDATE, если исполнение кода ещё не дошло до этого запроса, оно получается будет ещё доступна для запросов из другого кода?

Не понял, что имеется ввиду. Но если это про то - "будут ли видны изменения, которые сделаны до вызова этого UPDATE в транзакции", то это зависит от уровня изоляции других транзакций.
В случае SERIALIZABLE - нет, не увидят.

2) А если функцию sameFunc запустят много юзеров? Получается КАЖДЫЙ юзер будет ждать завершения предыдущих транзакций от всех остальных юзеров?

Так как указана SERIALIZABLE, то да:
- Если конфликтов не будет, т.е. никто не обновлял те же самые записи, то будут ждать
- Если кто-то одновременно обновил одни и те же данные, то будет конфликт транзакции

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

3) А если все запросы в транзакции взаимодействуют только с полями конкретного юзера, то как это нужно реализовать в транзакциях? Вроде как объект транзакции один — сам node.js, который единожды подключается к БД.

А вот тут надо разобраться. Зависит от того как ты работаешь с БД.
Судя по названию ты используешь пул соединений (переменная pool) и каждый раз выполняешь запрос на нем. Я не знаю node.js и фреймворк для БД, который ты используешь, но что-то подсказывает, что на каждый такой .query создается отдельное подключение и выполняется запрос.
Если да, то этот код работать не будет, т.к. ты постоянно открываешь новое соединение, начинаешь транзакцию или запрос и закрываешь соединение. В этом случае, все начавшиеся транзакции завершатся сразу, а запросы, которые должны работать в транзакции будут выполняться сразу.
Чтобы все работало корректно - на каждом вызове этого метода открывай новое соединение и работай с ним. Тогда гонки в коде не будет. (Можно еще использовать пул соединений).

Дополнительно я бы еще реализовал логику повторных попыток выполнения, если был обнаружен конфликт транзакций (проверяй исключение)