Ну принесут работнику две бумажки из отдела кадров — новый трудовой договор, или заявление об уходе — подписывай по своему выбору.

А остальные что, платят?

Я тут даже не знаю с чего здесь начать...

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

Про компании не интересно, интересно про работников, и тут есть два основных варианта:

1) Эти (редчайшие!) замечательные налогоплательщики почувствуют себя ФОПами, возрадуются снижению налоговой нагрузки и начнут палить бабло в казино и ресторанах)

2) Организация снизит им официальные зарплаты, и на руки им будут выплачивать все те-же деньги, а разница пойдет в прибыль работодателя

Ну или контора и работники поделят разницу в некотором соотношении

Я маю на увазі, шо після прийнятя цього закону, в Циклум прийде податкова і скаже:
Всі ващі ФОП — це приховані трудові відносини, переходьте на КЗпП — та сплачуйте 10%

І це правда, в цивілізованній краіні ця схема з ФОПами приведе до штрафу чи вязниці.

ІТ — це жирні вівці, яких по недогляду не чіпали — але іх стало так багато, що це так не залишиться
Або всім зниження податків, або нам іх поступово підвищать до загального рівня.

Это платформа, чтобы прикрыть схему с ФОП

Либо ИТ-сектор станет ядром политического движения, которое снизит налоги для загнанного под плинтус, нищего большинства, либо под плинтус загонят ИТ-сектор.

Схема с ФОПами — это «хак», несовместимый со здравым налогообложением.
Единственный шанс — добиться снижения налогов для остальных.

Этот волшебный способ называется публичными контрактами.

Вопрос был про что делать с изменениями схем.

Вот решил я изменить схему «специального database view» — каким боком мне знать, кто его читает (кроме всевидящей отчетности), и что они готовы к изменениям? Не деплоить пока не написали новый импорт/обработчик в отчетный контекст?

Кстати, поздравляю — у вас появился общий контекст, который всегда обновляют при изменениях схем/API.

По факту у вас теперь распределенный монолит.

А вот данные из других контекстов могут попадать в это хранилище разными способами

Можно список разных способов?

И что делать с изменениями схем сообщений/таблиц?

Собственно, у вас выходит, что если DDD приложение не музейная редкость без сквозной отчетности, то должен существовать некоторый отчетный контекст, в который «разными способами» попадает вся(!) информация, которая некоторым волшебным способом всегда именно в формате, понятном движку отчетности, вне зависимостти от того, что там мутят разработчики в отдельном контексте? Я все верно прочитал?

Ну, откровенно говоря, ваш пример с лотереей на «новую реальность» не тянет.

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

Мои возражения базируются на двух очень простых вещах:

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

Есть второй базовый пример практического облома изоляции контекстов — сводная отчетность. С удовольствием выслушаю ваш подход к реализации сквозной отчетности между разными базами. Дайте угадаю — все в шину публиковать?

Идемпотентность — это же про корректную обработку одного и того же события, полученного более одного раза, а не про срок его хранения?

Если событие вычистили из хранилища, то каким образом вы обеспечите идемпотентность при повторной публикации? Все подписчики пойдут его обрабатывать только один раз ... повторно.

Такое вполне себе случается, и решается версионированием схемы событий

Нет всегда, но проблемы изменения схемы в событийных архитектурах — это другая тема.

Именно изменение границ может произойти только при очень сильном перекраивании предметной области.

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

да, от DDD будет больше вреда, чем пользы.

На самом деле я сторонник DDD, особенно(!) в динамичных условиях, (и при этом противник EventSourcing в динамичных областях).
Просто я не думаю, что мы научимся дешево двигать границы контекстов, если спрячемся от критики. Есть проблема — ее решения надо искать.

Я возражаю против попыток натягивания подходов из three-tier на DDD вне рамок отдельно взятого контекста

Я собственно попрошу вас уточнить ваши возражения. Когда у вас есть 3+ взаимодействующих контекста, то шансы получить сложный граф их взаимодействия возрастают, возражаете ли вы или нет, но если в предметной области проявляется петля цикла, там где мы понадеялись на прямую линию — то все — приехали.
Невзаимодействующие контексты — это тривиальный случай — с ними нет проблем по определению, хоть в монолите, хоть в лямбдах.
Ну и мне не понятно, почему ролевая авторизация может быть «сверху», а основанная на правилах — не может.

Почему непросто? Для этого же давно придуман такой механизм, как идемпотентность.

Kafka, которая одновременно является и тем и другим

Кафка является и тем и другим в «некотором смысле» — практические применения шины подразумевают некоторый срок хранения сообщения (а богатых возможностей выборки не подразумевает вообще).

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

В ссылке на стековерфлоу автор ответа прямо замечает:

The challenge of this event-driven alternative is synchronizing the events.

Отдельный прикол с шинами — в эволюции имен и структур сообщений/событий — не приведи небо, сообщение называлось иначе и имело другую структуру (одно сообщение стало двумя разными), но это отдельная история.

Лоторейная система (за вычетом фильтра доступа) такая же составная часть бизнес логики, как и платежная система (вызовы к которой тоже могут проходить фильтрацию бизнес-правилами) — ну или поделитесь как вы их развели в разные категории.

Three-tier и DDD — не антиподы, контекст вполне может быть реализован как Three-tier.

... но и крайне не рекомендуют делать прямые зависимости между контекстами,

Насколько я понимаю проблематику, то разговор о изоляции без взаимодействия/пересмотра границ — не имеет смысла: на практике контексты взаимодействуют, и их границы перемещаются — никто мнения программиста об этом не спрашивает.

Собственно аббривиатура DDD подразумевает, что рулит предметная область, и структуризация проводится прежде всего исходя из предметной области (понимание которой меняется !).

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

Ну есть еще лямбда-экстремалы, которые любую команду деплоят отдельно)

Для начала мне кажется в своих размышлениях вы смешиваете DomainEvents с EventSourcingEvents и не различаете EventBus от EventLog.
Шина в общем случае — это канал передачи, а не общее хранилище с безлимитным сроком хранения и богатыми инструментами выборки.
Обеспечить безпроблемную повторную публикации события в шину (через три месяца) вам будет не просто. Ну и мы уже говорим о созависимом деплойменте как минимум.

Только, снова-таки, давайте не путать авторизацию в смысле выдачи определённых прав доступа администратором системы, и бизнес-правила, которые разрешают / запрещают определённые операции на основании предыдущих бизнес-транзакций.

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

Подробности — в студию!

Ни DDD, ни микросервисы не настаивают на горизонтальных отношениях между сервисами/контекстами, и точно так-же как в рамках контекста мы обращаемся к платежной системе, мы можем обратится к лоторейной системе — это к вопросу вложенности.

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

мне кажется, тогда было бы корректнее

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

Давай как-то скромнее

Ивенты не подходят, ибо а) их раньше не посылали, и если писать их для тебя — то где автономность (и это integration events)
б) идет речь о покупках за квартал (в прошлом), а лоторею надо запустить через недельку и к событиям прошлого (если они были вообще) доступа нет (если это не общая база — но это уже не шина).

Это к тому, кто и что попытался понять.

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

Таким образом мы попадаем в мир в котором, якобы изолированный контекст имеет тенденцию к нарастанию в спагетти-монстра,
и в котором одно дополнительное предложение в описании таски приводит к изменению границ между сервисами. А когда в любой момент микросервис прийдется вносить обратно в тело крупного контекста, программиста который решает отложить вынос, пока страсти с требованиями не улягутся — можно понять.

Там еще есть вариант когда между контекстами начинаются взаимоотношения в разрезе иерархии и вложенности, авторизацию можно выделить в интегрирующий слой Shared/Common.

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

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

Микросервис лотореи котторый ничего не знает про пользователей и покупки — это очень очаровательно звучит, но достаточно одного, достаточно обычного требования, чтобы эта картинка рассыпалась.

Списки можно посмотреть?

Замечательно, как теперь в рамках этой милой концепции вы реализуете функционал:
сервис лотореи в котором необходимо
разрешить вызов команды (регистрация в лоторее) только пользователям совершившим покупки в течение текущего квартала.

...
И кто-же это?
И где он берет свои знания, и как поддерживает их up to date?

А назначает их кто?

Приехали.
Жил-был монолит.
Год с одним программистом.
Два с двумя.
Три с пятью.

Вырос. Пришла пора разделять.
Где тут зло?