Entities\CostCenter, Entities\Surveyor, Entities\User

То, что класс не сущность подскажет неймспейс, а не окончание

Хотя если следовать этому принципу слепо то можно уперется в god object

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

То, что класс не сущность подскажет неймспейс, а не окончание

Так себе идея добавлять в неймспейсы имена каких-то паттернов и антипаттернов)

Так себе идея добавлять в неймспейсы имена каких-то паттернов и антипаттернов)

(Анти)Паттернов да, так себе, а вот отображать в нс с чем имеешь дело как раз очень верное решение

Куда лучше подхода уровня "красное не надевать, на порог не наступать"

"С чем имеешь дело" слииишком расплывчатое

Фабрика, синглтон, сущность, value object, менеджер. Что из этого ряда описывает "дело"? И каким образом эта информация помогает пользователю кода?

Модель, Контролер, Сущность

Что такое модель и что такое сущность, httpclient в этом делении это кто?

я скорее имел ввиду "собственные" части проекта. httpclient скорее всего будет внешним сервисом со своим собственным нс, да

кстати было бы интересно почитать, чтонибудь основательное про нейминг. есть что порекомендовать?

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe

By @fes0r

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe

данке)

вот кстати этот кусок мне спорным кажется: Для разделения директории на поддиректории должен быть определенный порог. Скажем если у вас в одной директории появляется 7+ файлов, это уже может послужить поводом для того чтобы задуматься и разделить структуру с использованием поддиректорий. У меня CRM с workflow конфигурируемым "на-лету" за каждый кусочек бизнес-процесса отвечает своя компонента (или несколько если в разных странах этот кусочек реализуется по разному). Компоненты сгруппированы в модули (опять же слелуя бизнес-процессу). НС этой части выглядит примерно так App\Modules\{SomeModuleName}\Components\{SomeComponentName} В итоге в директори компонент крупного модуля может быть 30+ файлов. Но все отлично читается, находится. Мне кажется делить на директори\подспейсы имеет смысл именно повторяя логику устройства приложения или бизнеспроцесса, а не по количеству

слышал такое, что бросать исключения в конструкторе - плохо

это правда?

нет

fail fast как говорится

вот кстати этот кусок мне спорным кажется: Для разделения директории на поддиректории должен быть определенный порог. Скажем если у вас в одной директории появляется 7+ файлов, это уже может послужить поводом для того чтобы задуматься и разделить структуру с использованием поддиректорий. У меня CRM с workflow конфигурируемым "на-лету" за каждый кусочек бизнес-процесса отвечает своя компонента (или несколько если в разных странах этот кусочек реализуется по разному). Компоненты сгруппированы в модули (опять же слелуя бизнес-процессу). НС этой части выглядит примерно так App\Modules\{SomeModuleName}\Components\{SomeComponentName} В итоге в директори компонент крупного модуля может быть 30+ файлов. Но все отлично читается, находится. Мне кажется делить на директори\подспейсы имеет смысл именно повторяя логику устройства приложения или бизнеспроцесса, а не по количеству

- порок в 7+ файлов может быть признаком того что пора дробить, а может и не быть. У меня есть модули содержащие по 30 файлов и норм. - модуль "components" так себе

слышал такое, что бросать исключения в конструкторе - плохо

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

DnsResolverInterface к примеру это часть поведения которая должна быть в классе Dns

да, все верно. Но если мы говорим о инфраструктуре там можно отойти от этого и сделать все чуть более процедурным

можешь загуглить доклады на тему functional core, imperative shell

ну и еще момент - очень сложно с таким подходом "дробить" систему. Вообще тема интересная)

Добрый день. Не совсем по теме, нет ли тут кого-нибудь, кто хорошо разбирается в adodb и загрузке данных из Экселя в экссес? Или может быть кто знает канал. Спасибо.

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe при таком подходе организации проекта, куда складывать какие то общие сервисы, взаимодействие между модулями. В общем что то общее. Создавать модуль common?

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe при таком подходе организации проекта, куда складывать какие то общие сервисы, взаимодействие между модулями. В общем что то общее. Создавать модуль common?

Что значит общее?

общих модулей быть не должно.

у тебя просто могут быть какие-то модули которые используются несколькими модулями

если у тебя есть модуль от которого зависят все - это называется god object и свидетельствует о том что у тебя что-то не так c декомпозицией и пришло время порефакторить

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

как правило все "общее" больше к инфраструктуре относится

http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

http://www.fullstackradio.com/38

Testing does not increase quality; programming and design do ?

Я таки нашел то о чем ты говорил про internal/external quality

Я таки нашел то о чем ты говорил про internal/external quality

Где?

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

как правило все "общее" больше к инфраструктуре относится

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

Где?

Growing object oriented software driven by tests вроде

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

не обязательно, можно просто юзать модуль нотификаций в инфраструктуре других модулей

Growing object oriented software driven by tests вроде

А, тогда там же)

ну то есть мне нравится второстепенную логику типа отправки нотификаций выносить на доменные ивенты

но это все будет происходить в рамках того же модуля где происходит магия, и просто относится к инфраструктуре модуля.

там уже могут быть зависимости от модуля нотификаций

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

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

почему нравится - потому что для вещей вроде нотификашен это идеально - у тебя есть четко прописанные тригеры и четко прописанные нотификации. Есть детальная связь какие нотификации по каким тригерам запускаются

и если у тебя добавляются дополнительные этапы жизненного цикла которые "смещают" тригер - это никак не аффектит код нотификаций

ну то есть почти никак

и тестить такое удобно

p.s. доменные ивенты не совсем тоже самое что и просто ивенты

p.s. доменные ивенты не совсем тоже самое что и просто ивенты

Еще такой вопрос возник. Например у нас три модуля. Юзер, Новость и комментарии. Сущности новость и комментарий связаны с сущностью Юзер. Нормально что связанная сущность находится в отдельном пространстве?

В отдельном модуле?

что сущности новости нужно от юзера?

аналогично для комментария

по хорошему - только айдишки оных

по сути тебе тут даже не нужно их между собой связывать.

пусть себе независимо живут

тут весь косяк и проблемы только с репрезентацией данных, когда тебе на одном скрине надо показать статью + все комменты + коротко профиль автора статьи + аватарки и никнеймы со ссылками на профили авторов комментов

то есть UI может жить в отдельном модуле и просто "собирать" нужную инфу у других

тут весь косяк и проблемы только с репрезентацией данных, когда тебе на одном скрине надо показать статью + все комменты + коротко профиль автора статьи + аватарки и никнеймы со ссылками на профили авторов комментов

Вот. Это меня и заинтересовало. Каким способом решается?

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

ERROR: S client not available

хочешь ты делать джойны в базе на уровне SQL или делать application-level join-ы

тут "правильного" способа нет

везде свои плюсы и минусы

если брать хипстерские подходы, то у меня было бы 3 независимых модуля никак не связанных между собой на уровне базы данных, graphql сервер который бы собирал для меня все воедино, и SPA на каком-нибудь ангуляре

или модуль который бы рендрил html срдствами сервера по той же абсолютно схеме

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

очень редко необходимо комменты "общие" для нескольких модулей, хотя такое бывает

Но все равно в посте и комменте нужно хранить какую то ссылку на пользователя. Так или иначе связь есть

Но все равно в посте и комменте нужно хранить какую то ссылку на пользователя. Так или иначе связь есть

ну это просто айдишка. можешь завернуть ее в VO с названием Author

ну или просто смерись что на 100% устранить зависимости между модулями не выйдет или выходит слишком дорого и пихай юзера)

но тогда просто сделай сущность юзера "легкой"

что бы там был только сферический юзер профайл

я например так такие вещи как креды и т.д. выношу в отдельную сущность Credentials

зачем при всем таком раскладе тогда надо application ?

если все так будет "НЕЗАВИСИМО" ?

А если взять выше и объединить это все под модулем блог?)

зачем при всем таком раскладе тогда надо application ?

что-то должно быть сверху и координировать процесс

так вот это сверху в виде фронтенда

говорит

мне надо ответ в таком формате

А если взять выше и объединить это все под модулем блог?)

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

и там и детали по новости, коментарию и пользователю

бэкенд говорит НЕТ мы так не делать это не канонично?

просто между "бэкэндом" и "фронтэндом" садишь агрегатор и все довольны

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

просто между "бэкэндом" и "фронтэндом" садишь агрегатор и все довольны

еще один бэкэнд или app

еще один бэкэнд или app

что значит еще один "бэкэнд"7

смотри, у тебя есть приложение, ты можешь его разбить на модули

получается у тебя фронт 1->1 бэкэнд 1->N бэкэнд-> база

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

нахера в этой цепочке 2 бэкенда и прослойка эта?