друпал

удобно, гибко, но ОЧЕНЬ медленно

И больно

и мышкой можно программировать

и мышкой можно программировать

Не любитель

ларавел смотрел?

Нет, щя чекну

На ларавеле намного больше панелек

Там соната и изиадмин только. Изиадмин ужасен, для того чтобы загрузить картинку нужны 3 (!!!) поля в бд, или городить свой велосипед для загрузки. А соната просто слишком тяжелая и половина функционала там не нужна.

любые генераторы админок боль

любые генераторы админок боль

Самому круды писать? А то чет лень загрузку картинок делать

ну так не делай)

https://github.com/choonkeat/attache

есть и другие подобные солюшены

Щяб руби заюзать

Ну ладно, я тебя понял

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

в целом можно тупо юзать крудогенераторы)

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

в 1000 строк

как в сонате

Ну это да, но там ж нет загрузки фоток

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

Над будет дописать

VichUploadBundle и подобные

p.s. хотя я их не юзаю

Окей

в целом если надо CRUD - проще laravel

У тебя нет таких задач?)

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

У тебя нет таких задач?)

у меня чисто апишки... 90% готового что есть ориентируется на сайтики

Ну да, такое. Только я с ларавел на вы. А проект надо хуяк хуяк и продакшон

Пока я подтяну ларавел пока напишу меня уже выебут

ну например.... hwi oauth bundle - 80% кода для того что бы достать токен пользователя из соц сети. а мне он уже готовый приходит и мне нужны только 20%

и так почти с каждой фигней

и в большинстве случаев вообще по нормальному не прикрутить

а апишки пилить как-то быстрее выходит

Тож хочу апи пилить

А то говном каким-то занимаюсь

Над в яву катиться

Апи под мобилки пилить

Влажные мечты

https://github.com/renatomarinho/laravel-gitscrum

папка app/Classes конечно вызывает вопросы

app/Classes/Helper еще больше

Ну это да, но там ж нет загрузки фоток

SonataMediaBundle же

SonataMediaBundle же

ну такое... есть вопросы.

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

Таки решил заюзать микрофреймворк + ручки

как думаете, уместно ли использовать сервер очередей для обмена данными между подсистемами распределённой системы? или лучше REST API?

как думаете, уместно ли использовать сервер очередей для обмена данными между подсистемами распределённой системы? или лучше REST API?

не является ли сервер очередей в этом случае единой точкой отказа?

да, является

ну то есть... если не является - норм (но по началу лишнее и rest-а хватает)

а если является - то это не микросервисы)

и не распределенная система, не понастоящему распределенная

а это не микросервисная архитектура

а какая?

распределенная ж система)

неправильно значит назвал

например, есть shop, admin и support, они как отдельные проекты, но должны поддерживать данные в синхронизации

на разных серверах

Может, поговорим о гексагональной архитектуре и DDD? Очень было бы послушать мнение людей на сей счёт) Кто как продумывает архитектуру проектов.

Особенно интересно, как постичь дзен без service container. Которого нет в проекте.

а с чего ты решил что это дерьмо? бабка нашептала?

Проекты типа Джумлы или Битрикса — это плохо поддерживаемая лапша из кода. И плагины к таким системам (Вордпресс сюда же) пишутся в таком же стиле.

ERROR: S client not available

Особенно интересно, как постичь дзен без service container. Которого нет в проекте.

ну а ddd его в свою очередь и не требует

ну а ddd его в свою очередь и не требует

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

Просто у нас тут компонентная разработка ТМ.

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

Проекты типа Джумлы или Битрикса — это плохо поддерживаемая лапша из кода. И плагины к таким системам (Вордпресс сюда же) пишутся в таком же стиле.

Суть в том, что такие проекты зачастую пишутся один раз и никак не поддерживаются.

Суть в том, что такие проекты зачастую пишутся один раз и никак не поддерживаются.

Конечно, потому что потом проще нафиг заново переписать. А это не есть хорошо.

неправильно значит назвал

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

Может, поговорим о гексагональной архитектуре и DDD? Очень было бы послушать мнение людей на сей счёт) Кто как продумывает архитектуру проектов.

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

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

принципы SOLID, инкапсуляция, GRASP

начни с этого

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

То есть, грубо говоря, адаптер может быть реализован в виде Factory, где есть некое дефолтное представление сервиса? Как, например, с абстракцией от БД.

То есть, грубо говоря, адаптер может быть реализован в виде Factory, где есть некое дефолтное представление сервиса? Как, например, с абстракцией от БД.

сделать фабрику из адаптера?

короч

мое мнение

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

https://www.youtube.com/watch?v=GRr4xeMn1uU

То есть, грубо говоря, адаптер может быть реализован в виде Factory, где есть некое дефолтное представление сервиса? Как, например, с абстракцией от БД.

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

> адаптер может быть реализован в виде Factory, где есть некое дефолтное представление сервиса? что такое "дефолтное представление сервиса"? Почему фабрика является адаптером? Она же фабрика, адаптеры это другие штуки

вот пример адаптера

http://www.globalsat.ru/Sites/global/Uploads/Adapter_pitaniya_220V_-_5V.FD0FF9CE4B884E6686A28A1C2751BAF2.jpg

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

DDD — это отдельная сложная вещь, я тут просто смешал всё в кучу, и правда))) хотелось начать разговор и о том, и о другом)

DDD — это отдельная сложная вещь, я тут просто смешал всё в кучу, и правда))) хотелось начать разговор и о том, и о другом)

что для тебя DDD?

читал ли ты Эванса?

(святое писание почти)

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

Разработка под предметную область.

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

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

мне каежтся, он больше не про ддд, а про модульную разработку. одна команда - один модуль. И такая структура (почему-то) у него не подразумевает сервис локейтор

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

Я честно пытался, но зашёл не с того угла.

мне каежтся, он больше не про ддд, а про модульную разработку. одна команда - один модуль. И такая структура (почему-то) у него не подразумевает сервис локейтор

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