Сообщение Re[10]: Что если не разделять строго dto, entity, bo... от 05.12.2025 8:22
Изменено 05.12.2025 10:00 Pauel
Re[10]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
P>>В этом случае вы даже не знаете, какая архитектура будет через год.
G>Никто не знает какая архитектура будет через год. Все кто утверждает обратное — скорее всего просто заблуждаются
Опаньки! И как же вы будете сверху вниз писать?
P>>Другое дело, когда вы лепите типовые проекты. Здесь ваши предположения гораздо точнее даже в отсутствие требований. И можно просто заранее заложить нужную архитектуру.
G>Откуда ты знаешь какая архитектура нужна на любом нетиповом проекте?
G>Понятно если если ты делаешь сайт-визитку, то они все плюс-минус одинаковые, и в принципы готовые решения-фреймворки есть, в рамках которых ты также двигаешься "сверху вниз".
Вы зачем то пересказываете то, что я вам сам же и сказал
Вы читаете или только пишете?
P>>Накидывание паттернов к этим двум подходам никак не относится. Например, решили, что "у нас будут микросервисов 100 штук, свяжем через очередь, хз зачем, детали накинем позже"
G>Как это будет реально выглядеть?
G>Вот ты сделаешь file->new project... как из этого получится 100 микросервисов, чем они будут заниматься?
В вашей ссылке на это ответ "the components themselves are still fuzzy". Обычно это так выглядит "вот здесь будет сервис, но что он будет делать, решим потом"
P>>Вот вам и top down, читаем вместе вашу же ссылку "With top-down design you start with a vision of the whole program, perhaps what some of the components are, and how they fit together, but the components themselves are still fuzzy. "
G>Так прочитай внимательно что написано — "вы начинаете с представления о всей программе, возможно, о некоторых её компонентах". То есть не надо заранее придумать ВСЕ компоненты. Если ты заранее проектируешь компоненты, а потом из них что-то работающее собрать — это проектирование "снизу вверх"
Нету никакого проектирования компонентов, есть исключительно представление о всей программе целиком. Ни про один из компонентов нет внятного представления. То есть, ровно то, о чем в вашей ссылке.
P>>В этом случае вы даже не знаете, какая архитектура будет через год.
G>Никто не знает какая архитектура будет через год. Все кто утверждает обратное — скорее всего просто заблуждаются
Опаньки! И как же вы будете сверху вниз писать?
P>>Другое дело, когда вы лепите типовые проекты. Здесь ваши предположения гораздо точнее даже в отсутствие требований. И можно просто заранее заложить нужную архитектуру.
G>Откуда ты знаешь какая архитектура нужна на любом нетиповом проекте?
G>Понятно если если ты делаешь сайт-визитку, то они все плюс-минус одинаковые, и в принципы готовые решения-фреймворки есть, в рамках которых ты также двигаешься "сверху вниз".
Вы зачем то пересказываете то, что я вам сам же и сказал
P>>Накидывание паттернов к этим двум подходам никак не относится. Например, решили, что "у нас будут микросервисов 100 штук, свяжем через очередь, хз зачем, детали накинем позже"
G>Как это будет реально выглядеть?
G>Вот ты сделаешь file->new project... как из этого получится 100 микросервисов, чем они будут заниматься?
В вашей ссылке на это ответ "the components themselves are still fuzzy". Обычно это так выглядит "вот здесь будет сервис, но что он будет делать, решим потом"
P>>Вот вам и top down, читаем вместе вашу же ссылку "With top-down design you start with a vision of the whole program, perhaps what some of the components are, and how they fit together, but the components themselves are still fuzzy. "
G>Так прочитай внимательно что написано — "вы начинаете с представления о всей программе, возможно, о некоторых её компонентах". То есть не надо заранее придумать ВСЕ компоненты. Если ты заранее проектируешь компоненты, а потом из них что-то работающее собрать — это проектирование "снизу вверх"
Нету никакого проектирования компонентов, есть исключительно представление о всей программе целиком. Ни про один из компонентов нет внятного представления. То есть, ровно то, о чем в вашей ссылке.
Re[10]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
P>>В этом случае вы даже не знаете, какая архитектура будет через год.
G>Никто не знает какая архитектура будет через год. Все кто утверждает обратное — скорее всего просто заблуждаются
Опаньки! И как же вы будете код сверху вниз писать не зная? Вам придется растить приложение архитектуру эволюционно, добавлять те или иные вещи по мере необходимости.
P>>Другое дело, когда вы лепите типовые проекты. Здесь ваши предположения гораздо точнее даже в отсутствие требований. И можно просто заранее заложить нужную архитектуру.
G>Откуда ты знаешь какая архитектура нужна на любом нетиповом проекте?
G>Понятно если если ты делаешь сайт-визитку, то они все плюс-минус одинаковые, и в принципы готовые решения-фреймворки есть, в рамках которых ты также двигаешься "сверху вниз".
Вы зачем то пересказываете то, что я вам сам же и сказал
Вы читаете или только пишете?
P>>Накидывание паттернов к этим двум подходам никак не относится. Например, решили, что "у нас будут микросервисов 100 штук, свяжем через очередь, хз зачем, детали накинем позже"
G>Как это будет реально выглядеть?
G>Вот ты сделаешь file->new project... как из этого получится 100 микросервисов, чем они будут заниматься?
В вашей ссылке на это ответ "the components themselves are still fuzzy". Обычно это так выглядит "вот здесь будет сервис, но что он будет делать, решим потом"
P>>Вот вам и top down, читаем вместе вашу же ссылку "With top-down design you start with a vision of the whole program, perhaps what some of the components are, and how they fit together, but the components themselves are still fuzzy. "
G>Так прочитай внимательно что написано — "вы начинаете с представления о всей программе, возможно, о некоторых её компонентах". То есть не надо заранее придумать ВСЕ компоненты. Если ты заранее проектируешь компоненты, а потом из них что-то работающее собрать — это проектирование "снизу вверх"
Нету никакого проектирования компонентов, есть исключительно представление о всей программе целиком. Ни про один из компонентов нет внятного представления. То есть, ровно то, о чем в вашей ссылке.
P>>В этом случае вы даже не знаете, какая архитектура будет через год.
G>Никто не знает какая архитектура будет через год. Все кто утверждает обратное — скорее всего просто заблуждаются
Опаньки! И как же вы будете код сверху вниз писать не зная? Вам придется растить приложение архитектуру эволюционно, добавлять те или иные вещи по мере необходимости.
P>>Другое дело, когда вы лепите типовые проекты. Здесь ваши предположения гораздо точнее даже в отсутствие требований. И можно просто заранее заложить нужную архитектуру.
G>Откуда ты знаешь какая архитектура нужна на любом нетиповом проекте?
G>Понятно если если ты делаешь сайт-визитку, то они все плюс-минус одинаковые, и в принципы готовые решения-фреймворки есть, в рамках которых ты также двигаешься "сверху вниз".
Вы зачем то пересказываете то, что я вам сам же и сказал
P>>Накидывание паттернов к этим двум подходам никак не относится. Например, решили, что "у нас будут микросервисов 100 штук, свяжем через очередь, хз зачем, детали накинем позже"
G>Как это будет реально выглядеть?
G>Вот ты сделаешь file->new project... как из этого получится 100 микросервисов, чем они будут заниматься?
В вашей ссылке на это ответ "the components themselves are still fuzzy". Обычно это так выглядит "вот здесь будет сервис, но что он будет делать, решим потом"
P>>Вот вам и top down, читаем вместе вашу же ссылку "With top-down design you start with a vision of the whole program, perhaps what some of the components are, and how they fit together, but the components themselves are still fuzzy. "
G>Так прочитай внимательно что написано — "вы начинаете с представления о всей программе, возможно, о некоторых её компонентах". То есть не надо заранее придумать ВСЕ компоненты. Если ты заранее проектируешь компоненты, а потом из них что-то работающее собрать — это проектирование "снизу вверх"
Нету никакого проектирования компонентов, есть исключительно представление о всей программе целиком. Ни про один из компонентов нет внятного представления. То есть, ровно то, о чем в вашей ссылке.