Здравствуйте, vsb, Вы писали:

C>>В общем, современная сервисная архитектура — это вообще отдельная и сложная тема. Хм. А не написать ли мне книгу про это?
vsb>А какой должна быть современная архитектура? Обязательны ли микросервисы или допустим монолит?
Монолит однозначно возможен и желателен. Для большинства приложений это оптимальный выбор.

Я бы сказал, что именно микросервисов не существует. Так как любой микросервис при правильной реализации перестаёт быть "микро", а становится вполне себе "макро".

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

vsb>Если брать конкретно на примере Java с РСУБД, как должно работать всё от начала до конца? Вот юзер тыкнул в браузере что-то. JavaScript приложение отослало REST запрос. На бэкэнде его кто принимает, Spring MVC? Ты против DTO, т.е. мы не пишем объект, на который маппится JSON, а работаем с ним как с Map<String, ?>?
Оптимально — сразу отображаем в целевой объект, который мы потом можем записать в базу (через ORM).

Ещё у себя использую такой паттерн:

type SubtaskInfo struct {
  Id String
  CommandLine []string
  ...
}

// Структура, которая хранится в БД посредством ORM
type StoredSubtask struct {
   SubtaskInfo // "Наследуемся" от SubtaskInfo

   RowId string
   Version int64
...
}

SubtaskInfo сгенерирован из Swagger-схемы для почти-REST-интерфейса.

Работа с базой — как обычно. В начале запроса открываем транзакцию, пишем/читаем данные через ORM или ручные запросы, в конце запроса фиксируем/откатываем. Без транзакций с NoSQL всё тоже похоже.