Асимметрия модульного монолита

[Dhwtj]

От технологического стека зависит. Например, если вас чёрт дёрнул писать богатую бизнес логику на Go, то тактический DDD, и большой монолит будет чужеродным решением. Rust - отлично. С#, Java - чуть хуже из-за проблем GC с большим объемом памяти. Go - чужеродно. TS - не знаю, он вроде как выразительный, но тоже GC

write side модуля в отдельный сервис, но оставить общую БД для чтения

Cqrs наоборот делает: жирная логика любит монолит: агрегаты и бизнес правила любят проверку compile time. А для чтения пофиг, можно вынести в сервисы и отдельные базы или материализованные вьюхи с агрегацией

[A_Kubit]

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

[Dhwtj]

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

[kreout]

У контракта на чтение есть ещё семантика, которую проверка схемы не поймает. В вашем примере с total и НДС имя и тип столбца могут сохраниться, а итог отчёта уже изменится.

Я бы дополнил инвентаризацию потребителей небольшим набором контрольных заказов: с НДС и без, с возвратом, с частичной отгрузкой. Для затронутых отчётов зафиксировать ожидаемые суммы и прогонять реальные SQL-запросы на старой и новой модели данных. Особенно в переходный период Expand/Contract, когда обе формы данных ещё живут одновременно. Это даёт предметный критерий готовности потребителей к удалению старых столбцов.

[A_Kubit]

Спасибо, хорошее дополнение. В моём примере я предполагал более грубый случай: было два столбца, total и vat, а стал один total с НДС внутри. Но вы правы — изменения могут носить более тонкий характер и такие проверки действительно могут помочь, особенно в переходный период.

[rukhi7]

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

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