Ну я больше про то, что нельзя точно сказать выполнен SRP принцип или нет

Ну если вы определили весьма точно грань детализации и весьма четко расставили обязанности - то опять таки, почему нет?

Врали ему

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

Что такое класс context?)

На хабре штук 10 статей и каждая не маленькая...

который передает состояние системы, ее связей. Как я это понимаю.

Ну вот только к тому же излишнее разделение тоже портит код. Зачем дробить то, что меняться скорее всего будет только одним образом и вместе. Это только ухудшит читаемость и займет время. Поэтому это правило полезно, когда уже интуитивно понимаешь что лучше.

Так я и не говорю излишне разделять. Я про достаточный уровень детализации

Шо за херня)

Штука которая все связывает ВНЕЗАПНО может стать год обджектом

Жаль лень читать статью что б разобраться что это за треш

😂👍

Я это привел не как пример хорошего чтива, а скорее, что у каждого свое недопонимание одного, как-бы простого принципа.

В целом так, но лучше раздробить и склеить если неудобно

Всегда был вопрос: вот есть мелкие агрегаты. Тут приходит заказчик и накидывает инвариант, который захватывает 2 агрегата (т.е. если он был один - было бы лучше под новый кейс) . Перепиливается полсистемы под новый склеенный агрегат или что?

Тру инварианты которые должны форситься на уровне агрегата так просто не возникают

вот давай я тебе приведу пример который вот у меня сча перед глазами. У тебя есть пациенты. У них есть номера (чет типа номера карточки). Номера должны быть уникальными, так? Как проверить что это true invariant?

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

Или другой пример - есть система которая позволяет тебе продавать вещи со склада. Вроде есть инвариант что количество проданных айтемов не может быть больше количества айтемов на складе - но для бизнеса внезапно важно трекать ситуации когда "яблок было 10 а продали 11" потому что это хороший индикатор что кто-то ворует.

Мы просто привыкли что можно ебнуть везде констрейтны в базе и вжух все красиво и консистентно. На самом деле реальность куда интереснее и сложнее

Спасибо за развернутые примеры! Но они покрывают кейс, когда инвариант - "не" инвариант, а не про объединение агрегатов. Хотя я что-то не могу придумать пример, когда дейсвтительно надо объединять :)

Могу ли 2 агрегата менять одну рид-модель?