Хуяк и в продакшн сила

SOLID'ом тебе по голове постучать)

а если я захочу RDB -> Nosql

то что делать?

В том то и смысл, если есть шанс того, что понадобится изменить одну либу на другую , тогда выделяй интерфейс и оперируй им в доменном слое

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

а если я захочу RDB -> Nosql

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

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

значит тебе надо поменять платформу на что то более быстродействующее

Нужно смотреть на бд, если не хватает мощности при вертикальном масштабировании , тогда использовать но горизонтальное

а если я захочу RDB -> Nosql

и ты наперед будешь закладывать это в разработку?

и ты наперед будешь закладывать это в разработку?

та это никак не получится нормально заложить

следуем YAGNI принципам?

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

никто не будет менять тип бд в проекте который уже работает

ну я вообще когда вижу очередной интерфейс в коде - становится грустно

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

а если я захочу RDB -> Nosql

Серебряной пули нет Придется дописывать новый репозиторий или dao, прокидывать его в сервис и не париться Зависит от архитектуры текущего проекта

да ниче не придется

Лишь бы в контроллерах не писать flush, вот тогда начинается дичь

я согласен что надо находить баланс, максимально стараться абстрагироваться, но насчет смены фреймворка это жоска

контроллерах..

Лишь бы в контроллерах не писать flush, вот тогда начинается дичь

а где писать поделись соображениями

щас бы писать флаш где-то внутри сервисов

а то может все что я тут нахватался - просто чушь и всё делаю неверно

щас бы писать флаш где-то внутри сервисов

OMG

а где писать поделись соображениями

При анемичной модели пиши в dao

а где писать поделись соображениями

после транзакции)

а без анемичной модели

где писать?

а то может все что я тут нахватался - просто чушь и всё делаю неверно

При DDD и иже с ними, в репозиториях

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

я проверю твою инфу

если бизнес логика вообще есть)

В некоторых случаях хватает сервис + repository + dto + entity

если бизнес логика вообще есть)

Она однозначно есть, разве что ты не бложик пилишь и то там тоже есть behavior rules

В некоторых случаях хватает сервис + repository + dto + entity

95% пхпшных проектов

если бизнес логика вообще есть)

Если бизнес логики нет, то это БД)

Dto для чего нужно?

В некоторых случаях хватает сервис + repository + dto + entity

Up

Dto для чего нужно?

Для передачи данных между слоями

Между репозиторием и сервисом к примеру?

95% пхпшных проектов

Тут нужно разделять проекты и модули Есть простые проекты, но один модуль будет сложным , а программисты по привычке используют один и тот же подход

Если бизнес логика слишком сложна, то можно рассмотреть DCI

Некоторым это может быть полезно

Она однозначно есть, разве что ты не бложик пилишь и то там тоже есть behavior rules

кодовая база 500тыс+, ну чуть больше чем бложик и чистой бизнес логики как кот наплакал

У меня на работе был чел с 5 летним опытом, пишущий модуль для бухгалтерского учета, используя функции , жёсткую привязку к либам и при поддержке хотелось повеситься Это насчёт самописов )

>бухгалтерского учета вот

инфраструктуры минимум, бизнес логики максимум

кодовая база 500тыс+, ну чуть больше чем бложик и чистой бизнес логики как кот наплакал

Что для тебя бизнес-логика ? Проект что ли похож на набор crud страниц , не взаимодействующих между собой ?

Все взаимосвязи сущностей - уже бизнес логика

Если я composer пакет хочу задействовать, то я уже должен привязать его через интерфейс?

Тот же guzzle к примеру

Если я composer пакет хочу задействовать, то я уже должен привязать его через интерфейс?

Выдели интерфейс и прокидывай объект через IoC (DI , к примеру )

Ну и главный вопрос. Как понять мне что нужен DDD?

Может он не нужен?

посиди тут в чате и тебе вообще понадобится любая технология про которую тут расскажут

в итоге будешь пилить пару лет

ну или пока бабло не кончится на проекте )))

Угу

DCI и DTO это DDD?

И возможно ли по пути внедрить DDD?

Ну и главный вопрос. Как понять мне что нужен DDD?

Это приходит с опытом, посмотри на проект Как долго планируется его поддерживать , учти ещё десяток факторов , о которых мы здесь не упомянем , так как после работы/нет опыта и реши )

Что для тебя бизнес-логика ? Проект что ли похож на набор crud страниц , не взаимодействующих между собой ?

ну к примеру терабайты данных, которые приходят, их нужно максимально быстро обработать, сохранить, проиндексировать и тд. бизнес логики не так уж и много, и она идет вперемешку с инфраструктурным кодом как можно догадаться модули, которые можно описать на десятке А4 страниц, при этом чистой бизнес логики там будет ну 5-10% максимум, остальное это инфраструктурные вещи и оптимизации

DCI и DTO это DDD?

DCI - вообще не к тому , это о том, как работать с инвариантами связей DDD - про управление сложностью в проекте

ну к примеру терабайты данных, которые приходят, их нужно максимально быстро обработать, сохранить, проиндексировать и тд. бизнес логики не так уж и много, и она идет вперемешку с инфраструктурным кодом как можно догадаться модули, которые можно описать на десятке А4 страниц, при этом чистой бизнес логики там будет ну 5-10% максимум, остальное это инфраструктурные вещи и оптимизации

Обработка терабайт данных на php... Окей Здесь и не требуется сложных архитектурных решений Вообще big data - про костыли и оптимизацию , а не про архитектуру

И возможно ли по пути внедрить DDD?

Твой проект может эволюционировать, как и все в этом мире )

DCI - вообще не к тому , это о том, как работать с инвариантами связей DDD - про управление сложностью в проекте

Инвариантность связей это как?

Обработка терабайт данных на php... Окей Здесь и не требуется сложных архитектурных решений Вообще big data - про костыли и оптимизацию , а не про архитектуру

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

ERROR: S client not available

как думаешь, в фб, вк, одноклассниках и тд сильно дрочат на ДДД?)

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

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

как думаешь, в фб, вк, одноклассниках и тд сильно дрочат на ДДД?)

Костыли на костылях и многие вещи переписаны с php на си )

НО, проектов с такой адовой логикой ну не так уж и много

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

Почему обработка терабайт данных - не big data?

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

чтобы законить уютный вечер

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

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

все еще жду пример правильного проекта (

все еще жду пример правильного проекта (

Ты ещё не понял что их нет?

Ты ещё не понял что их нет?

ну страницы пиздежа же про них есть

Емае... Весь мир вообще то так построен

все еще жду пример правильного проекта (

Двач

Все так красиво на словах. В реальности иначе

Правильной архитектуры нет)

Мир изначально не совершенен

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

И стремится к хаосу

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

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

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

идеальная программа - нет программы)

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

вот по поводу ДДД

>У меня есть альтернативная гипотеза, про которую тоже не знаю, насколько она верна: многим людям нужно как-то доказывать себе и окружающим, что они очень умные. Поэтому есть каста людей, которые ни на что не променяют программирование на C++ или Scala во всей полноте этих языков: это такой способ чувствовать себя очень умным. Вот человек справился с очень сложной штукой, и он будет использовать её дальше, чтобы подтверждать свою невероятную компетентность и талантливость, потому что не всякий может освоить систему такой сложности. И даже если для конкретной задачи система прагматически не обязана быть такой сложной, человеку может нравиться это делать, просто потому что «я же умею такую крутейшую вещь, а вы не умеете».

это цитата

Yagni

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

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

это цитата

Бывает и такое, неоправданная сложность - зло

Иногда некому человека остановить

А если он ещё и жадный на знания

DDD, микросервисы, CQRS/ES и тд часто пихают там где это не нужно