для тех кто by tech компоновкой кода занимается а не by feature

Гексагональная архитектура +- and package by feature

На данный момент мне нравиться идея слоёв в комбинации с port/adapter. Не знаю где тут детство) пока все стало в процессе значительно лучше...

Пока с ридмоделью в голове не бьется потому что она по сути - набор DTO/View/Projection и набор фетчеров жестко связанных с конкретной БД. И это выбивается из идеи слоев.

Рид модели обычно заводят для того что бы максимально использовать преимуществах ранилища и максимально оптимизировать модель данных под задачу.

То есть "абстракция от хранилища" не имеет тут смысла. Ты если решишь заменить хранилище скорее всего тебе нужна будет другая модель данных

Точнее корень противоречий помому из смешения двух идей... переиспользуемого "ядра" и "вынесения бизнес логики в доменный слой"...

То есть в том кейсе который я писал, ядро должно содержать основную бизнес логику, быть независимым от инфраструктуры (доступа к БД и т.д.), оно подключаемое из отдельного пакета. Инфраструктуру реализует и подсовывает в порты ядра проект-консюмер.

И в этом кейсе какая-то рид-модель жестко завязанная на БД никак не выносится в ядро. Возможно это что-то несовместимое.

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

оч осторожно надо со словом "переиспользуемого"... code reuse в классическом смысле это "расширение" а не "взять кусок кода и заюзать где-то еще. Просто уточняю что мы про одно и то же говорим.

"ядро" редко переезжает из приложения в приложение и уж тем более ивенты смены хранилища оч редкое событие. Примерно такое же редкое как смена языка

> И в этом кейсе какая-то рид-модель жестко завязанная на БД никак не выносится в ядро. Возможно это что-то несовместимое.

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

которая "слушает" ивенты ядра и строит модельку.

а ядро пусть отвечает за write часть и консистентность стэйта

рид модельки ж строятся на основе консистентного стэйта а значит "не консистентными" они быть не могут)

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

🙏🏼

спасибо

думаю детство тут в том, что пока у тебя 2 калеки на проекте - ты не будешь чувствовать боли, а вот когда 20 начнёт вылезать газиллион проблем на всех уровнях

каких например?

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

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

ну это больше про каплинг. проблема слоев - этот концепт увы не дает хороших границ и не оч способсвует information hiding. А люди оч любят "слои" перекладывать на "структуру проекта"

но как упражнение для детелй на тему separation of concerns удобно