«перемикач»?

По сравнению со всеми остальными жопорукосделанными так называемыми шаблонизаторами на php, xslt — очень мощный универсальный стандартизированный инструмент. Очень жаль, что он не стал мэйнстримом.

Бизнес партнеры — сейчас за ними все следят и как только они плохое сделаю По и Ко протрубят

Ты им дал шанс. Они сделали плохое. Протрубили. И что? — тебе ж всё похер.

Слабое государство — с таким мнением тебя нужно депортировать

Бестолочь, иди книжки читай ))
Государство должно быть слабым.

Хороший вариант. Сделайте ещё один шаг вперёд — поменяйте private на public final ;)

Часто бачили шоб замість аррайліста підсовували шось інакше?

Ну вот в данном случае — как раз «да». Например, Collections.emptyList() или из guava — Lists.asList()

Если Вы пишете либу, то наверно у Вас есть интерфейс, который имплементит та или другая реализация. А если этот интерфейс завязан на филды реализации, то наверно это уже не либо, а что-то черти что ;)

Раскройте пожалуйста подробней вопрос — чем билдер отличается от сеттеров, и почему Вы считаете это ФП?

Отличный пример того, как в купе с неправильным пониманием инкапсуляции следует неправильное понимание наследования и полиморфизма. Ваш код нарушает L (и, вероятно, O) из SOLID.

Практические советы:
— class должен быть либо abstract, либо final;
— в абстрактных классах должны быть абстрактные методы;
— неприватные неабстрактные методы абстрактных классов должны быть final.

Согласен с Иваном — пример не очень. Получается внедрение в класс знаний о внешних форматах.

Самые существенные риски — одни и те же. Поэтому, «намного» — это только если выбирать сейчас депозиты, типа, 9% годовых )).

Рантье на недвиге в Украине во-первых геморно, а во-вторых сильно невыгодно. Вы в итоге получите доходность на уровне банковских депозитов (в лучшем случае), при гораздо более низкой ликвидности.

Ключевое слово — «диверсификация». Золото, недвига, ПИФы — слишком высокий риск сами по себе, но если всё в портфель — самое оно.

Имхо, оптимальный вариант — зарубежные инвестиционные страховые программы + индексные фонды + индексы по золоту + разное по мелочи при желании. На локальном рынке, к сожалению, ничего с разумным соотношением риск/прибыль я для себя не нашёл.

Погуглите «волатильность золота», а потом оцените — стоит ли так рисковать.

Мне нужен один, как единая и неделимая транзакция

Если бизнесу это не надо, то зачем оно Вам?

Я Вам о том, что реализовать без подсистемы легко и просто невозможно

А я Вам — о том, что реализация распределённых транзакций это не просто три строчки кода, а такая же «подсистема», только дорогая, глючная и неподдерживаемая. Реализация «альтернативного» решения будет стоить копейки, а бизнес получит такой же результат «и даже лучче».

как я могу это перепроектировать?

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

это будет целая подсистема

и всё равно это будет лучше (= надёжнее и дешевле), чем транзакции.

Умение правильно формулировать вопрос для того, чтоб получить точный ответ — это один из основных навыков архитектора. И я бы не называл это манипуляцией.

несколько вариантов решения с ТЭО по каждому

Так и я об этом же. Сделайте сравнение ТЭО с транзакцией и без один раз — и этот вопрос больше вообще никогда не будет подниматься.

по-моему, это очень распространённый кейс

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

Как именно оно будет реализовано — отдельный вопрос. Мне кажется, можно придумать массу вариантов. Если запись в БД — самый стрёмный момент, поменяйте действия местами, и пишите сначала туда, а потом загружайте файл. Или разбейте это на три шага — оформление «запроса на upload», сам upload и формирование сущности «мета + файл». Вобщем. сделайте три микросервиса вместо одного, сделайте два раунда запрос/ответ на клиенте вместо одного, и всё равно это будет лучше (= надёжнее и дешевле), чем транзакции.

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

мы о транзакциях в принципе или о распределённых?

Распределённые транзакции совместимы с MSA.

Да, мы о распределённых транзакциях.

Отличный вопрос. Второй день думаю как сформулировать лаконичный и точный ответ, не написав при этом ещё одну статью ). Далее — имхо.

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

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

Тезисно, кажется, как-то так.