тип такого

В отличие от сервис/класс/интерфейс

в папке соответствующего модуля, которому они принадлежат

в какой папке =) то етсь там куча из интерфейсов для контроллеров, сервисов и тд?

https://github.com/php-fig/log/blob/master/Psr/Log/LoggerInterface.php а это говно код ?

это хороший код, но PSR не требует таких названий

не требует но использует

стандарт де факто

в какой папке =) то етсь там куча из интерфейсов для контроллеров, сервисов и тд?

нет, у меня нет такие разбухшие папк

не требует но использует

где?

в других стандартах использует

а

ну ок

так как они тогда лежат? можно пример , мне ради интереса

де факто а не де юро

нету правильного подхода

ну имхо это все по проекту надо смотреть, прям мантры нет на этот счет

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

вот вот

кому-то нравится крафтовое пиво, кому-то нет ))

идея с UserController мне не нравится но она применяется

так как они тогда лежат? можно пример , мне ради интереса

https://github.com/json-api-php/json-api/tree/master/src/Document

https://www.dropbox.com/s/8567yf0oy1mut2z/Screenshot%202017-03-28%2010.32.36.png?dl=0

ну вот я смотрю и в душе не догадываюсь что PrimaryData это интерфейс

потом я полез внутрь там увидел что его имплементят , полез обратно и тока тогда допер =)

ну вот я смотрю и в душе не догадываюсь что PrimaryData это интерфейс

а зачем тебе это знать?

то есть пока я не открыл

это я про наглядность кода

стандарт де факто

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

у каждого свое имхо

а зачем тебе это знать?

+

ну походу для опенсорса стоит использовать

class Controller\User { method (Model\User $user)}

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

просто потому что "у нас так принято"

мое имхо, psr это хорошо, что не регламентированно там : интерфейсам префикс(в конец названиям), трейтам префикс (в конец названия), абстрактным классам префикс (в начало названия)

названия вида UserController - это плохо лучше Controller\User

Почему такая практика стала популярной вместо доменной организации, User/Controller.php Model.php ...

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

Не по доменам?)

Не по доменам?)

да.

речь про DDD

Типа группировка по фиче vs группировка по типу?

про ddd сказать не могу

но обычно в миру есть FooInterface и рядом папка foo где лежат его имплементации

Типа группировка по фиче vs группировка по типу?

да. Но не тип, а уровень, по факту.

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

Она топ

layer (controller, model, view, etc_

Если не умеете, то лучше по типу собирать

Потом научитесь

я где то нарывался на статью где описывались разные подхода в java

к именования с плюсами и минусами

и кем они приняты

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

вот мне и странно, что вроде Фабьен умный чувак. ,а организовал код таким образом. И всякие юи в след за ним же.

вот мне и странно, что вроде Фабьен умный чувак. ,а организовал код таким образом. И всякие юи в след за ним же.

Опять же. По типу проще => снижен порог вхождения

например видел в namespace добавляли impl и там доменная модель, а интерфейсы без impl

Вряд ли доменная молель там)

ну доменная да громко

Опять же. По типу проще => снижен порог вхождения

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

так в основном легаси крупных интерпрайз было

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

Никто не мешает делать иначе

А для новичков лучше простую структуру

Никто не мешает делать иначе

да эт понятно что не мешает, но прост интересно, может какое-то логическое обоснование для этого есть, которое я упустил

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

да эт понятно что не мешает, но прост интересно, может какое-то логическое обоснование для этого есть, которое я упустил

Маркетинг)

А для новичков лучше простую структуру

плохому же учит. и потом мигрировать - уж больно адово получается.

Не

Если новички по фиче сортировать будут, то будет хуже

Это как тесты на бихате. Это очень сложная штука

ERROR: S client not available

Если новички по фиче сортировать будут, то будет хуже

почему же? как раз весь хлам в одном месте и проще разрулить, чем когда куча классов по куче мест раскидано.

почему же? как раз весь хлам в одном месте и проще разрулить, чем когда куча классов по куче мест раскидано.

Правила что к какой фиче относится очень туманны

почему же? как раз весь хлам в одном месте и проще разрулить, чем когда куча классов по куче мест раскидано.

хорошо вопрос где должны быть интерфейсы?

Надо эванса читать

в таком подходе

В модуле

в каждой фитче свои интерфейсы?

что такое модуль?

в каждой фитче свои интерфейсы?

Да

я не обладаю телепатическими навыками

Бывает

Да

ок как с этим работать должно условно назовем ядро (фреймворк и тд)

Как в симфе

Успешно работает

пример можно ?)

Вот у мня тут счас такой проект. кроме контроллеров и моделей еще vo (по фактц гад-классы), facade, adapter, factory и (та-дам!) services

На мануал настройки контейнера?

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

внедрили

хорошо вопрос где должны быть интерфейсы?

в отдельной папке фичи User/Interface/AdminInterface.php e.g.

Я предлагаю юзать то, что юзается в симфе

контроллер где будет лежать?

Order/Controller.php

в отдельной папке фичи User/Interface/AdminInterface.php e.g.

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

контроллер где будет лежать?

да там же все.

Order/Controller.php

хорошо а зависимости между модулями как менеджется?

на этапе настройки di ?

Ну да

Надо эванса читать

У Эванса все чотко изложенно. причем продукт-ориентировано с расчетом на бизнес - а это всегда вин. Причем позволяет успешно делать проекты в которых бизнес не зачто в аджайл не хочет.

ну не плохо тогда

У Эванса все чотко изложенно. причем продукт-ориентировано с расчетом на бизнес - а это всегда вин. Причем позволяет успешно делать проекты в которых бизнес не зачто в аджайл не хочет.

Ну хз

По мне так очень размыто