Size: a a a

Saint P Ruby Community

2020 November 09

EM

Eugene Maslenkov in Saint P Ruby Community
Каждое решение кем-то выстрадано (не помню оргинальной цитаты Джоэля Спольского, но мне кажется она отвечает на твой вопрос ;)).
Рельсы - офигенны для "быстрого" старта. Соответственно 90% проектов это либо rails-way либо зарефакторенный rails-way. (IMHO)
источник

RI

Rustam Ibragimov in Saint P Ruby Community
Kirill Kaiumov
Добрый вечер. Поделитесь, пожалуйста, у кого какая ситуация с архитектурой в рельсовом проекте? Rails way? Rails way, но с папочками app/services, app/decorators и тп? DDD? Clean Architecture? Hexagonal architecture? Что-то иное?

Просто во всех рельсовых проектах, в которых я работал, не были ничего и близко к тому, о чем пишут в книгах по DDD или говорят на конфах по архитектурам. И это были большие проекты, которые пилились много лет многими командами.

В текущем проекте (относительно новом) хочется сразу делать норм архитектуру, чтобы легко вносить изменения и тп, потому что, как показывает опыт, потом уже будет очень сложно что-то изменить, не будет времени и тд.

P.S. Микросервисы не предлагать 😄
а что сразу мешает в новом проекте по ддд писать?
источник

RI

Rustam Ibragimov in Saint P Ruby Community
да и проекты разные бывают. не всегда спустя годы в успешном бизнесе получается переехать со старной архитектуры на новую. обычно это процесс небыстрый и может прохожить годами
источник

CM

Cucumba Morozov in Saint P Ruby Community
Книги по ддд это дело очень контекстоспецифичное. Что Вернон, что Эванс, что Влашин живут в своих мирах и своем времени. Не все вещи будут выглядеть так, как они рекомендуют

Я в своих проектах не могу выделить верхнеуровневую архитектуру. Модульность? Когда как. Ддд? Когда как. Рельса? Когда как

Это же не так важно. Важно, куда с этим идем.

Есть однозначное зло — big design upfront. Вот этим заниматься не надо. Отсюда и пошли истории про аджайл и итеративное* *проектирование*.

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

RR

Ruslan Ryabov in Saint P Ruby Community
я думаю, что надо прочувствовать, то как организовать, то что сейчас тут напишут, может и поможет чем-то, но может так же создать трудности, если не понимать, зачем такая организация в проекте
лично я за то, чтобы логику выносить в сервисы, дробить приложение на слои, и по хорошему абстрагироваться от работы именно с АР
источник

AG

Alexander G in Saint P Ruby Community
Kirill Kaiumov
Добрый вечер. Поделитесь, пожалуйста, у кого какая ситуация с архитектурой в рельсовом проекте? Rails way? Rails way, но с папочками app/services, app/decorators и тп? DDD? Clean Architecture? Hexagonal architecture? Что-то иное?

Просто во всех рельсовых проектах, в которых я работал, не были ничего и близко к тому, о чем пишут в книгах по DDD или говорят на конфах по архитектурам. И это были большие проекты, которые пилились много лет многими командами.

В текущем проекте (относительно новом) хочется сразу делать норм архитектуру, чтобы легко вносить изменения и тп, потому что, как показывает опыт, потом уже будет очень сложно что-то изменить, не будет времени и тд.

P.S. Микросервисы не предлагать 😄
В последних проектах, был rails way + app/services
В предпоследнем это был rails way + dry (валидации, схемы, DI)
В текущем нет rails. grape + dry.

Но по сути это все одно и то же. Лично у меня не получается сделать так, чтобы потом хвастаться и говорить "вот - clean architecture"
:(
источник

RI

Rustam Ibragimov in Saint P Ruby Community
Eugene Maslenkov
Каждое решение кем-то выстрадано (не помню оргинальной цитаты Джоэля Спольского, но мне кажется она отвечает на твой вопрос ;)).
Рельсы - офигенны для "быстрого" старта. Соответственно 90% проектов это либо rails-way либо зарефакторенный rails-way. (IMHO)
а откуда цифра в 90% 🤔 не прикапываюсь, просто интересно (90% рынка проанализирлвать - это очень много 🤔 откуда столько инфы? :))
источник

AG

Alexander G in Saint P Ruby Community
Cucumba Morozov
Книги по ддд это дело очень контекстоспецифичное. Что Вернон, что Эванс, что Влашин живут в своих мирах и своем времени. Не все вещи будут выглядеть так, как они рекомендуют

Я в своих проектах не могу выделить верхнеуровневую архитектуру. Модульность? Когда как. Ддд? Когда как. Рельса? Когда как

Это же не так важно. Важно, куда с этим идем.

Есть однозначное зло — big design upfront. Вот этим заниматься не надо. Отсюда и пошли истории про аджайл и итеративное* *проектирование*.

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

EM

Eugene Maslenkov in Saint P Ruby Community
Rustam Ibragimov
а откуда цифра в 90% 🤔 не прикапываюсь, просто интересно (90% рынка проанализирлвать - это очень много 🤔 откуда столько инфы? :))
Это цифра с потолка, хотел написать 99 XD. Но передумал. Работал в разных проектах. И не однократно сталкивался с тем что "особенности" в архитектуре или принятии других решений (например выборе технологического стека) были избыточны. Cucumba прав, нужно просто писать так, что бы твой код не было больно менять. И да, вопросов это создаёт больше чем даёт ответов. Но хоть понятно, к чему стремиться.
источник

RI

Rustam Ibragimov in Saint P Ruby Community
я думаю, что код нужно не только так писать, очень много хороших принципов и подходов было придумано и изучено :) как и разные ситуации бывают на проектах, и разные цели на их, разные их размеры и потребности в стеке технологий и в виде архитектуры в разный момент времени и роста. я думюа надо не торопиться, быть гибким, в меру дальновидным, и  несомненно, целиться на рефакторящийся код
источник

AG

Alexander G in Saint P Ruby Community
так-так, к чему пришли-то? надо писать хороший код? поддерживаю! )
источник

AD

Anton Davydov in Saint P Ruby Community
источник

RI

Rustam Ibragimov in Saint P Ruby Community
Alexander G
так-так, к чему пришли-то? надо писать хороший код? поддерживаю! )
а как иначе :) иногда даже неочень код - это хорошее решение в данный момент воемени :)
источник

A

Anton in Saint P Ruby Community
Kirill Kaiumov
Добрый вечер. Поделитесь, пожалуйста, у кого какая ситуация с архитектурой в рельсовом проекте? Rails way? Rails way, но с папочками app/services, app/decorators и тп? DDD? Clean Architecture? Hexagonal architecture? Что-то иное?

Просто во всех рельсовых проектах, в которых я работал, не были ничего и близко к тому, о чем пишут в книгах по DDD или говорят на конфах по архитектурам. И это были большие проекты, которые пилились много лет многими командами.

В текущем проекте (относительно новом) хочется сразу делать норм архитектуру, чтобы легко вносить изменения и тп, потому что, как показывает опыт, потом уже будет очень сложно что-то изменить, не будет времени и тд.

P.S. Микросервисы не предлагать 😄
В последнем проекте растаскатал всё по модулям, которые объединены в контексты. В моделях в основном только конфигурация - связи, енумы и т п, вся логика вынесена в сервисные объекты соответствующих модулей (папочки типа listeners, presenters, policies, workers и др) лежат в папке соответствующего модуля. Даже значения enum повыносил в отдельные объекты references. Практически везде single responsibility что позволяет максимально переиспользовать функциональность, ну и тестами легко покрывать. В целом доволен, легко ориентироваться и менять функциональность отдельных модулей
источник

DS

Dmitriy Strukov in Saint P Ruby Community
Kirill Kaiumov
Добрый вечер. Поделитесь, пожалуйста, у кого какая ситуация с архитектурой в рельсовом проекте? Rails way? Rails way, но с папочками app/services, app/decorators и тп? DDD? Clean Architecture? Hexagonal architecture? Что-то иное?

Просто во всех рельсовых проектах, в которых я работал, не были ничего и близко к тому, о чем пишут в книгах по DDD или говорят на конфах по архитектурам. И это были большие проекты, которые пилились много лет многими командами.

В текущем проекте (относительно новом) хочется сразу делать норм архитектуру, чтобы легко вносить изменения и тп, потому что, как показывает опыт, потом уже будет очень сложно что-то изменить, не будет времени и тд.

P.S. Микросервисы не предлагать 😄
У меня на проекте RPC
источник

A

Anton in Saint P Ruby Community
а ну и rails way в моем понимание это когда магия происходит неявно. Достаточно большую часть выполнять явно, тогда будет проще разбираться в коде, хотя кода может быть побольше
источник

KK

Kirill Kaiumov in Saint P Ruby Community
Anton
В последнем проекте растаскатал всё по модулям, которые объединены в контексты. В моделях в основном только конфигурация - связи, енумы и т п, вся логика вынесена в сервисные объекты соответствующих модулей (папочки типа listeners, presenters, policies, workers и др) лежат в папке соответствующего модуля. Даже значения enum повыносил в отдельные объекты references. Практически везде single responsibility что позволяет максимально переиспользовать функциональность, ну и тестами легко покрывать. В целом доволен, легко ориентироваться и менять функциональность отдельных модулей
Спасибо. Если в моделях есть связи, наверняка было такое, что модель из одного модуля имеет ассоциацию на модель из другого модуля. Что с этим делали?
источник

A

Anton in Saint P Ruby Community
Kirill Kaiumov
Спасибо. Если в моделях есть связи, наверняка было такое, что модель из одного модуля имеет ассоциацию на модель из другого модуля. Что с этим делали?
а модели я не развносил по контектам, они общие
источник

A

Anton in Saint P Ruby Community
я было хотел попробовать, то мне показалось что это будет трудоемко, так как к такой структуре я пришел спустя месяц разработки. Может в след раз когда новый проект начну 🙂
источник

KK

Kirill Kaiumov in Saint P Ruby Community
Anton
я было хотел попробовать, то мне показалось что это будет трудоемко, так как к такой структуре я пришел спустя месяц разработки. Может в след раз когда новый проект начну 🙂
Понятно :) а чем идейно отличаются у вас контексты от модулей? Можете пример привести?
источник