что такое orderProfit

слои это лож

тортик ложь да в нём намёк (на группировку объектов и зависимости)

тортик ложь да в нём намёк (на группировку объектов и зависимости)

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

если у тебя больше десятка файлов - "слои" плохая идея для формирования структуры кода

Я накидывал лиж бы быстрее сделать, для себя. Но хочу красиво, а как незнаю ((

если у тебя больше десятка файлов - "слои" плохая идея для формирования структуры кода

В моём случае как лучше?

хз, это надо смотреть что умеет квери билдер твоего любимого yii

скорее всего не очень много

да это построитель запросов, ОРМ

ничего он толком не умеет, Если что-то сложное, проще ручками

1. построитель запросов это НЕ ORM. Это две разные концепции. ORM может быть и Без "строителя запросов" 2. я прекрасно знаю что это такое - я к тому что тебе по сути над ним нужно свой билдер замутить под свою задачу.

если у тебя больше десятка файлов - "слои" плохая идея для формирования структуры кода

м… а какая структура организации — правильная? у меня есть пакет с объектами домена, пакет с моделями базы, с апи и приложением. или это совсем неправильно?

Здесь ОРМ строит запрос, ну по факту это экземпляр класса, который особо ничего не умеет, так. Небольшие запросики. Если говорить о чём то серьъёзном(под серъёзным я понимаю это работа с типами POINT в геометрии и так далее) то он не умеет

м… а какая структура организации — правильная? у меня есть пакет с объектами домена, пакет с моделями базы, с апи и приложением. или это совсем неправильно?

смотри с позиции coupling-а между твоими пакетами и cohesion-а оных. С увеличением количества элементов твоего пакета связанность этих пакетов будет взлетатьт просто космически. И главное что твоя структура никак не будет помогатьт с определением местарасположения кода

Здесь ОРМ строит запрос, ну по факту это экземпляр класса, который особо ничего не умеет, так. Небольшие запросики. Если говорить о чём то серьъёзном(под серъёзным я понимаю это работа с типами POINT в геометрии и так далее) то он не умеет

бля не ORM строитт запрос.... ай пофигу

короч сами сражайтесь и сами гуглите

короч сами сражайтесь и сами гуглите

Я понял тебя, я не прав про ОРМ. Я просто так привык называть класс который строит запрос )

билдер я иммею ввиду

да, слова они нужны просто так. И смысл их вообще не важен. Пойду попью чай (я просто так кофе привык называть)

да, слова они нужны просто так. И смысл их вообще не важен. Пойду попью чай (я просто так кофе привык называть)

Хватит меня стебать )

смотри с позиции coupling-а между твоими пакетами и cohesion-а оных. С увеличением количества элементов твоего пакета связанность этих пакетов будет взлетатьт просто космически. И главное что твоя структура никак не будет помогатьт с определением местарасположения кода

м… да. но ведь внутри пакета связей ещё больше локализуется. а какой солюшн? как-то группировать вокруг агрегатов?

м… да. но ведь внутри пакета связей ещё больше локализуется. а какой солюшн? как-то группировать вокруг агрегатов?

допустим у нас есть пакет домена и пакет с моделями базы. Как много зависимостей у тебя внутри модели базы? И как много зависимостей между моделями базы и доменом? Каких стрелочек будет больше? И еще момент - часто стрелочки появляются просто так. Я нахожу занятным такую возможно неочевидную идею как... разные концепты одной сущностит могут быть представлены разными моделями с одинаковой айдишкой.

м… да. но ведь внутри пакета связей ещё больше локализуется. а какой солюшн? как-то группировать вокруг агрегатов?

группировать вокруг функционала. Это не просто, требует того что бы ты понимал за счет чего функционал появился. Кому и зачем он нужен - это позволяет предсказать изменения в оном (не конкретно что поменяется, а просто где скорее всего поменяется вместе).

типа... ложить рядом то что меняется вместе, ложить раздельно то что меняется раздельно

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

Да слои это такая вещь, которая должна появляться сама собой

Да слои это такая вещь, которая должна появляться сама собой

раскрой мысль

как выражается "появление" и что всетаки такое слой?)

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

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

да, это считается связью. Почитай про такие метрики как afferent/efferent coupling и попробуй прогнать свой код)

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

монолит прям

м… а микросервисная архитектура — это про это?

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

Ну вот например если ты пишешь на фп языке, то ты по итогам всегда сможешь в конце разделить что есть какой «слой». Потому что там на уровне типов то что взаимодействует с сетью не может взаимодействовать с логикой напрямую. Пишешь код как обычно, а потом можно нарисовать эти 3 слоя и разместить названия функций, и все функции будут четко в этих слоях

м… а микросервисная архитектура — это про это?

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

чую, что по метрики будут очень деморалищующими

Ну вот например если ты пишешь на фп языке, то ты по итогам всегда сможешь в конце разделить что есть какой «слой». Потому что там на уровне типов то что взаимодействует с сетью не может взаимодействовать с логикой напрямую. Пишешь код как обычно, а потом можно нарисовать эти 3 слоя и разместить названия функций, и все функции будут четко в этих слоях

но на структуру проекта это влиятьт не особо должно, так?

Да

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

Так же решает проблему отказоустойчивости

Так же решает проблему отказоустойчивости

или создает ее)

отказоустойчивость и с монолитами хорошо работает.

Поэтому я и говорю, что оно по итогам-то ляжет в эти слои, но изначально на это опираться не думаю что стоит)

с микросервисами у тебя просто отказоустойчивость начинает сильно важной быть

это как переход от просто децентрализованной системы к распределенной

много боли, слез и хайпа

хато можно потом на митапах и конфах выступать типа "как мы запихнули все по докер контейнерам и называем это микросервисной архитектурой"

хато можно потом на митапах и конфах выступать типа "как мы запихнули все по докер контейнерам и называем это микросервисной архитектурой"

))

давно к слову не скидывал видос на эту тему: https://www.youtube.com/watch?v=Fuac__g928E

там и про слои чуть-чуть шуткуют

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

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

вот видосик посмотри

что до слоев - моя мысль на данный моментт такая - слово Layer можно спокойно заменить на Concern и смысл не меняется. но только если ты используешь Concern то оно меньше как-то просится влиятьт на структуру кода твоего проекта)

разделение на эти самые консерны важная штука, но повтотрюсь - это мало относится к структурированиюю проекта на пакеты

Ну вот например если ты пишешь на фп языке, то ты по итогам всегда сможешь в конце разделить что есть какой «слой». Потому что там на уровне типов то что взаимодействует с сетью не может взаимодействовать с логикой напрямую. Пишешь код как обычно, а потом можно нарисовать эти 3 слоя и разместить названия функций, и все функции будут четко в этих слоях

Это не мешает говнокодить ровно так же как обычно

Фаулер кстати упоминал, что слои не первичны, слои присутствуют у уже разделённого на секции приложения

Это не мешает говнокодить ровно так же как обычно

Если есть зачатки здравого смысла, то мешает

Если есть зачатки здравого смысла, то мешает

Я к тому, что от фп тут лучше не становится

В этом плане мне кажется там всё намного более прозрачно, с ООП в здравом уме можно вакханалию городить всё равно, всё как-то расплывчато

Ну либо у меня деформация уже какая-то, я после клинкода был уверен, что с ООД всё вообще понятно, а щяс возвращаясь в эти диалоги понимаю что тут постоянно бурление по мелочам

Структуру папок обсуждают, когда её можно поменять полностью за 20 минут

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

Ну либо у меня деформация уже какая-то, я после клинкода был уверен, что с ООД всё вообще понятно, а щяс возвращаясь в эти диалоги понимаю что тут постоянно бурление по мелочам

хз как по мне вопрос структуры проекта никак не зависит от ФП или там ООП.

Структуру папок обсуждают, когда её можно поменять полностью за 20 минут

Для этого потребуется сначала обсудить структуру папок чтобы получить гибкий проект) Ничего не даётся за просто так

особенно если когда я говорю "ООП" я имею ввиду не говно с классами а эктотры больше, но это другая история.

хз как по мне вопрос структуры проекта никак не зависит от ФП или там ООП.

Да тут никто не спорит)

Структуру папок обсуждают, когда её можно поменять полностью за 20 минут

ее почти всегда можно поменять полностью за 20 минут.

просто в некоторых случаях после этотго не все будет работать ;)

Идея вроде норм справляется, почти не было проблем

А если и были то поправить не сложно было

особенно если когда я говорю "ООП" я имею ввиду не говно с классами а эктотры больше, но это другая история.

event driven

что до слоев - моя мысль на данный моментт такая - слово Layer можно спокойно заменить на Concern и смысл не меняется. но только если ты используешь Concern то оно меньше как-то просится влиятьт на структуру кода твоего проекта)

а вот интересно, есть ли разница между concern и responsibility ? Separation of concern и single responsibility principle выглядят очень уж похожими друг на друга

Это одни и те же принципы только на разных уровнях архитектуры

т.е если single responsibility обычно про один класс/компонентик то Separation of concern это более высокий уровень абстракции, что то по типу модулей целой системы

SRP спокойно ложится на любой уровень

тортик ложь да в нём намёк (на группировку объектов и зависимости)

Часто можно наблюдать(и сам так делал), что начинаешь загоняться по этим слоям и совершенно игнорируешь bounded context, которые вероятно более важная штука, нежели эти перевязанные друг с другом слои

Эта картинка лучше.

т.е если single responsibility обычно про один класс/компонентик то Separation of concern это более высокий уровень абстракции, что то по типу модулей целой системы

"компонентик" - это уже фактически что угодно =\

т.е если single responsibility обычно про один класс/компонентик то Separation of concern это более высокий уровень абстракции, что то по типу модулей целой системы

А что если я скажу, что в пыхе ты юзаешь классы как модули?

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

А что если я скажу, что в пыхе ты юзаешь классы как модули?

С каким-нибудь di container в качестве резолвера модулей

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

OCP это тоже переизобретенный Information Hiding

ну в целом основопологающие принципы структурного дизайна типа coupling/cohesion, SoC и т.д. просто подаются под новым соусом. Например Information Hiding -> low Coupling Hight Cohesion -> SRP + OCP -> Protected Variations (факт, Кокберн говорил что просто не знал про OCP) -> Connascence

time is a flat circle

fat circle

time is a donut

https://cdn.skim.gs/image/upload/b_rgb:FFFFFF,bo_1px_solid_rgb:EDEDED,c_pad,f_auto,fl_lossy,h_382,q_auto,w_682/homer-simpson-doughnuts

ну в целом основопологающие принципы структурного дизайна типа coupling/cohesion, SoC и т.д. просто подаются под новым соусом. Например Information Hiding -> low Coupling Hight Cohesion -> SRP + OCP -> Protected Variations (факт, Кокберн говорил что просто не знал про OCP) -> Connascence

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

нет

потому что структурное программирование и потому что goto considered harmful

Ladies ang gentlemans

А что вы юзаете для ревью? Ну т.е. нужно же пометки делать где что исправить

может есть какой то спец софт

Ой, кажется оффтоп

На гитхабе в репе пр открываешь и ревьювишь)