DT
Так он от write части вообще никак не зависит,кроме подписки на события
тогда ложи куда удобнее, какая разница?
Size: a a a
2020 October 19
СП
тогда ложи куда удобнее, какая разница?
Не имея опыта тяжело понять где же удобнее)))
DT
Не имея опыта тяжело понять где же удобнее)))
представь, тот факт что рид моделька эта оказалась в одном проекте по счастливой случайности и не более того. Куда бы ты ее положил? Может ли она вообще вне папки с проектом лежать?
СП
я бы сложил рядом то что относится к одной и той же функциональности (меняется по схожим причинам) а не "логически" мол репозитории к репозиториям контроллеры к контроллерам. Мол по фичам а не по техническим аспектам. Или "соблюдая SRP формировал пакеты/модули/неймспейсы")
А так - как хочешь так и делай, тебе ж этой структурой пользоваться) можно максимум порекомендоват почитать про information hiding, low coupling hight cohesion
А так - как хочешь так и делай, тебе ж этой структурой пользоваться) можно максимум порекомендоват почитать про information hiding, low coupling hight cohesion
Ну вот все что касается комментариев сложил в одну папочку, а вот внутри уже не до конца явно как лучше все разложить
SP
код который обновляет рид-модельки - вообще отдельный код, и чем дальше он от write модели, тем лучше (дальше в плане зависимостей от write части)
достаточно в другом файле, не перегибай
СП
представь, тот факт что рид моделька эта оказалась в одном проекте по счастливой случайности и не более того. Куда бы ты ее положил? Может ли она вообще вне папки с проектом лежать?
Ну теоретически конечно может отдельно.... Но как-то не удобно
DT
достаточно в другом файле, не перегибай
если его не связывает ничего, кроме структурок сообщений, зачем его вообще куда-то во write часть ложить
SP
если его не связывает ничего, кроме структурок сообщений, зачем его вообще куда-то во write часть ложить
зачем делать врайт часть как отдельный модуль? think about it :)
СП
А сама идея, что реад по событию сохраняет для себя дополнительную информацию - это норм?
DT
зачем делать врайт часть как отдельный модуль? think about it :)
ты с другой стороны зашел, рид - это как код где-то сбоку, свои структурки, свои инфраструктурные дела. про write я не говорил)
SP
Не имея опыта тяжело понять где же удобнее)))
есть простой способ разобраться. Задай вопрос что ты хочешь от структуры. Например вот вопросы которые у меня к структуре возникают:
- куда положить новую штуку? Вот делаю я новую фичу и мне надо куда-то файлики положить? куда? почему?
- как разобраться что есть в проекте, мол я новенький и открыв структуру проекта вижу application/domain/infrastructure/etc - круто, не оч помогает
- как обеспечить границы зон ответственности. не "слои" а именно что когда я работаю с комментами мне в целом не оч надо трогать посты или там темы. Мол представь что "разные люди за разные фичи отвечают".
- как обеспечить учет зависимостей между модулями. Как трекать кто от кого зависит. Мне надо трекать что инфраструктура зависит от домена или мне надо трекать какие фичи от каких зависят?
- куда положить новую штуку? Вот делаю я новую фичу и мне надо куда-то файлики положить? куда? почему?
- как разобраться что есть в проекте, мол я новенький и открыв структуру проекта вижу application/domain/infrastructure/etc - круто, не оч помогает
- как обеспечить границы зон ответственности. не "слои" а именно что когда я работаю с комментами мне в целом не оч надо трогать посты или там темы. Мол представь что "разные люди за разные фичи отвечают".
- как обеспечить учет зависимостей между модулями. Как трекать кто от кого зависит. Мне надо трекать что инфраструктура зависит от домена или мне надо трекать какие фичи от каких зависят?
АЯ
я вообще чем больше работаю тем больше понимаю что правильное название - это 80% работы
DT
Ну тоесть появились у тебя проекции на колоночной БД, там еще в редис проекция пошла, и шо, все в Comments/Read пихать?)
АЯ
и да, джавастайл - это не правильное название.
SP
Ну тоесть появились у тебя проекции на колоночной БД, там еще в редис проекция пошла, и шо, все в Comments/Read пихать?)
если это только про комменты то да, может быть какие-то общие вещи которые более общие проблемы решают еще куда поместить
SP
мол "инфраструктурная часть комментов" может зависеть от общей инфраструктуры
SP
опять же, это все сложно переваривать когда людей с кодом работают мало (до 10-ти например). Когда мы начинаем говорить о 10-ти командах это все куда важнее)
SP
ну и да, до N людей в целом плевать вообще - разберетесь)
SP
хотя зависимости трекать будет сложнее
SP
как советует Парнас - если вы хотите придумать как поделить систему на модули выпишите список того что может меняться и выстраивайте границы так что бы каждый модуль "прятал" в себе информацию о деталях реализации и давал возможность "менять" эти детали не трогая другие модули)