Пожалуй да. Можно подумать, что компоненты лежащие на одной грани не могут взаимодействовать с компонентами на другой грани, но на схеме нет явного разделения, что может привести к неоднозначному восприятию архитектуры.
Я сторонник "Явное лучше не явного" и слоистая архитектура на мой взгляд более явно демонстрирует разделение компонентов на слои.
Действительно, эти архитектуры во многом схожи, хотя разница в деталях.
Например здесь неплохой разбор Clean Architecture и представление ее в слоистой схеме.
Мне лично, не нравится этот способ представления. Как подметил автор:
Однако, можно заметить, что UI и Data Access компоненты расположены в одном слое
Кампоненты расположенные в одном слое должны иметь полный доступ друг к другу.
То есть UI имеет полное право обращаться к Data Access, что не правильно само по себе. И ни одна из схем не противоречит этому.
Понятно, что авторы подразумевали нечто другое, но это савсем не очевидно из схемы.
А вот схема слоистой архитектуры достаточно наглядно даёт понять невозможность взаимодействия UI и Data Access компонентов.
У меня похожая проблема, но ещё хуже.
Я без понятия как монетизировать проект.
У меня полно конкурентов которые предоставляют похожие услуги бесплатно.
И аудитория в общем не готовая платить.
Мой опыт говорит, что Windows это не прихоть, а необходимость.
В некоторых компаниях, политика компании разрешает только Windows. Не разрешает виртуалки и вторую ось. А локального админа, чтоб хотя бы hosts править, приходится вымаливать через руководство.
И не подумайте, что компании плохие, просто админам так проще, когда у них несколько сотен компов, а разрабов, которым нужны никсы, всего десяток или два.
С той же проблемой сталкиваются дизайнеры на маках.
Решений проблемы много.
В одной из компаний мне не давали локального админа. Я плюнул и притащил свой ноутбук с ubuntu. Тоже решение.
А по подробней можно?
Мне с ходу в голову приходит только ограничение доступа к файлам и отслеживание начала скачивания/проигрывания видео.
Отслеживание проигрывания лучшие делать через плеер. Больше возможностей и контроля.
Как резерв конечно можно сделать отслеживание скачивания на сервере.
Я приятно удивлен увидеть статью про яхтинг на Хабре.
Добавлю пару комментариев.
Согласование терминологии
В яхтинге единые правила и терминология МППСС. Единственное что в мировых водах используется английская терминология, а в Российских внутренних водах русская терминология.
У меня с этим были затыки так как большая часть опыта именно во внутренних водах. Но это просто слова, суть одна и та же.
Расходы на топливо, по мнению нового капитана, должны были дополнительно оплачиваться экипажем, хотя владелец говорил о других условиях. Сумма за счет многочисленности экипажа вышла небольшая, около 20 евро.
Когда у меня был переход по Атлантике 1200 мм, мы за свой счёт залили полный бак, все канистры что были и я ещё уговаривал капитана купить дополнительных канистр и взять с собой топлива побольше, потому что это серьезный переход и свою жизнь я ценю больше.
В последствии, мы сильно жалели, что взяли мало топлива так как у нас вместо обещанных 40 узлов попутного ветра всю дорогу был штиль и топлива до берега не хватило.
Это море. Нужно всегда ориентироваться на самое худшее.
Правда, он ограничился только самыми необходимыми вопросами — сколько яхтенного опыта
По большому счету это все что нужно.
Также желательно заранее узнать у команды об их аллергии, болезнях, списке лекарств, их применении и местоположении. Если у кого-то на борту неожиданно случится приступ, это будет очень не хорошо.
Описывать свои достижения капитан не обязан. Авторитет капитана неоспорим. Это на берегу вы можете сказать, а на воде ваша жизнь зависит от капитана. Если капитан сказал прыгать за борт, матрос должен тут же исполнять команду.
«дойти до точки В» и «стараться не повредить яхту» — существенно отличающиеся цели
Почему отличающиеся? Это напрямую связанные цели. На поврежденной лодке вы можете не дойти до точки В и обратное тоже верно.
Первоочередная цель в любом яхтенном переходе это дойти из точки А в точку Б. Желательная цель дойти целыми, но мы помним что жизнь человека ценнее лодки.
Я не знаю какая у вас была ситуация и что вы называете при свежем ветре. Если была отдана такая команда, то на это, я думаю, были причины.
Как уже говорил ранее, команды капитана не обсуждаются.
посуду мыли только при помощи ручной помпы
При наличии ручной помпы, очевидно что пользоваться нужно только ей. Этого не знают только те кто никогда не имел дела с ней.
Это не критика. Я тоже на эти грабли наступал.
капитан не проинструктировал экипаж и вахту о необходимом оповещении его в этой ситуации
Ну это просто смешно.
При любой внештатной ситуации нужно поднимать капитана, даже если он уснул 10 мин назад.
Это ваш косяк, а не капитана.
команды вроде «Уберитесь на камбузе», «Отдайте кормовые»
Ну, мы всё же не в армии.
Команды вроде "Ты идёшь убираться на камбузе" и "Ты встаешь на левый кормовой" четки, понятны, эффективны и особенно важны в интернациональных командах. Но иногда хорошо бы дать право выбора.
В моей практике не редко звучат команды "Подготовится к швартовке" и "Кто на кормовых?".
Подитожу
На мой взгляд, яхтинг больше похож на армию, чем на классический менеджмент. Матрос который ни чем не занят, плохой матрос.
Соглашусь. Если какое-то действие в сущности одного контекста должно стригерить действие в сущности другого контекста, то конечно логично делать это через доменные события.
У меня подобное подвешено на события от заказа, в частности когда заказ становится оплаченным.
Если событие обрабатывается в сущности заказа, как в моей библиотеке, то все гуд. Я это и предлагал.
А вот если вы начисляете бонусы за оплаченный заказ в отдельном сервисе слушателе, то это не есть хорошо. Это пример размазывания бизнес логики по проекту, что часто встречается при использовании событийно-ориентированного подхода.
Скорей: начисление бонусов рефералу за создание заказа.
Пересчет делается в сущности реферала, а вот инициировать процедуру начисления бонусов можно через заказ.
Согласен с Fesor. Очень трудно говорить не зная особенностей бизнеса.
Например мне не понятно почему вы не можете пересчитывать бонусные баллы реферала дважды?
Они пересчитываются по разным событиям и количество начисляемых баллов может, а скорей всего и будет, различаться. Также хорошо бы сохранить в истории начисления баллов за что их начисляли каждый раз. То есть опять же нужно сохранять их раздельно.
По идее, вам надо по каждому событию от заказа пересчитывать баллы рефералов и генерить событие обновления счета, их агрегировать и отправлять рефералу уведомление с подробным отчётом за что и сколько он получил баллов.
Да. И не только. Например для соблюдения SRP, часть кода можно вынести в обработчик событий, но чтоб не размазывать бизнес логику по проекту, её можно сохранить в сущности.
Например, тот же пример от Fantyk можно решить через обработку событий в сущности заказа.
Я в это случае создаю CQRS команду на отправку SMS уведомления на каждое событие и кладу ее в очередь уникальных команд и по крону разбираю очередь.
Это даёт нам и сохранение уникальности уведомлений и позволяет не тормозить клиент на отправку SMS и контролировать нагрузку на сервер отправки SMS.
Кроме стандартного агрегирования событий ещё позволяет обрабатывать события в самой сущности, имеет функционал для реализации слушателей, подписчиков, очередей и middleware
Ну если прям для савсем савсем простых CRUD проектов которые не планируют развивается, то да. Сгодится. Правда я с такими проектами не работаю.
Мои проекты либо сразу сложнее, либо гарантированно будут усложняется и тогда внедрение сонаты только время сэкономит.
Спасибо за ссылку.
Не знал про EasyAdminBundle.
Но похоже EasyAdminBundle ещё больше завязан на антипаттерне Anemic model, чем SonataAdminBundle.
И конфигурирование форм в yaml файлах попахивает чем-то.
И не понятно как использовать свои FormType
Пожалуй да. Можно подумать, что компоненты лежащие на одной грани не могут взаимодействовать с компонентами на другой грани, но на схеме нет явного разделения, что может привести к неоднозначному восприятию архитектуры.
Я сторонник "Явное лучше не явного" и слоистая архитектура на мой взгляд более явно демонстрирует разделение компонентов на слои.
Действительно, эти архитектуры во многом схожи, хотя разница в деталях.
Например здесь неплохой разбор Clean Architecture и представление ее в слоистой схеме.
Мне лично, не нравится этот способ представления. Как подметил автор:
Кампоненты расположенные в одном слое должны иметь полный доступ друг к другу.
То есть UI имеет полное право обращаться к Data Access, что не правильно само по себе. И ни одна из схем не противоречит этому.
Понятно, что авторы подразумевали нечто другое, но это савсем не очевидно из схемы.
А вот схема слоистой архитектуры достаточно наглядно даёт понять невозможность взаимодействия UI и Data Access компонентов.
У меня похожая проблема, но ещё хуже.
Я без понятия как монетизировать проект.
У меня полно конкурентов которые предоставляют похожие услуги бесплатно.
И аудитория в общем не готовая платить.
Мой опыт говорит, что Windows это не прихоть, а необходимость.
В некоторых компаниях, политика компании разрешает только Windows. Не разрешает виртуалки и вторую ось. А локального админа, чтоб хотя бы hosts править, приходится вымаливать через руководство.
И не подумайте, что компании плохие, просто админам так проще, когда у них несколько сотен компов, а разрабов, которым нужны никсы, всего десяток или два.
С той же проблемой сталкиваются дизайнеры на маках.
Решений проблемы много.
В одной из компаний мне не давали локального админа. Я плюнул и притащил свой ноутбук с ubuntu. Тоже решение.
Ну вот как бы да. Зачем php если все прекрасно разруливается через nginx?
Профит какой?
А по подробней можно?
Мне с ходу в голову приходит только ограничение доступа к файлам и отслеживание начала скачивания/проигрывания видео.
Отслеживание проигрывания лучшие делать через плеер. Больше возможностей и контроля.
Как резерв конечно можно сделать отслеживание скачивания на сервере.
У меня только один вопрос.
Зачем стримить видео через php?
Чем не угодил nginx?
Я приятно удивлен увидеть статью про яхтинг на Хабре.
Добавлю пару комментариев.
В яхтинге единые правила и терминология МППСС. Единственное что в мировых водах используется английская терминология, а в Российских внутренних водах русская терминология.
У меня с этим были затыки так как большая часть опыта именно во внутренних водах. Но это просто слова, суть одна и та же.
Когда у меня был переход по Атлантике 1200 мм, мы за свой счёт залили полный бак, все канистры что были и я ещё уговаривал капитана купить дополнительных канистр и взять с собой топлива побольше, потому что это серьезный переход и свою жизнь я ценю больше.
В последствии, мы сильно жалели, что взяли мало топлива так как у нас вместо обещанных 40 узлов попутного ветра всю дорогу был штиль и топлива до берега не хватило.
Это море. Нужно всегда ориентироваться на самое худшее.
По большому счету это все что нужно.
Также желательно заранее узнать у команды об их аллергии, болезнях, списке лекарств, их применении и местоположении. Если у кого-то на борту неожиданно случится приступ, это будет очень не хорошо.
Описывать свои достижения капитан не обязан. Авторитет капитана неоспорим. Это на берегу вы можете сказать, а на воде ваша жизнь зависит от капитана.
Если капитан сказал прыгать за борт, матрос должен тут же исполнять команду.
Почему отличающиеся? Это напрямую связанные цели. На поврежденной лодке вы можете не дойти до точки В и обратное тоже верно.
Первоочередная цель в любом яхтенном переходе это дойти из точки А в точку Б. Желательная цель дойти целыми, но мы помним что жизнь человека ценнее лодки.
Я не знаю какая у вас была ситуация и что вы называете при свежем ветре. Если была отдана такая команда, то на это, я думаю, были причины.
Как уже говорил ранее, команды капитана не обсуждаются.
При наличии ручной помпы, очевидно что пользоваться нужно только ей. Этого не знают только те кто никогда не имел дела с ней.
Это не критика. Я тоже на эти грабли наступал.
Ну это просто смешно.
При любой внештатной ситуации нужно поднимать капитана, даже если он уснул 10 мин назад.
Это ваш косяк, а не капитана.
Ну, мы всё же не в армии.
Команды вроде "Ты идёшь убираться на камбузе" и "Ты встаешь на левый кормовой" четки, понятны, эффективны и особенно важны в интернациональных командах. Но иногда хорошо бы дать право выбора.
В моей практике не редко звучат команды "Подготовится к швартовке" и "Кто на кормовых?".
Подитожу
На мой взгляд, яхтинг больше похож на армию, чем на классический менеджмент.
Матрос который ни чем не занят, плохой матрос.
Зря вы так. Мне вот интересно было что вы изобрели.
Хоть бы ссылку на гитхаб кинули.
если что, кроме
kernel.terminateесть ещеconsole.terminate(пруф)Соглашусь. Если какое-то действие в сущности одного контекста должно стригерить действие в сущности другого контекста, то конечно логично делать это через доменные события.
Если событие обрабатывается в сущности заказа, как в моей библиотеке, то все гуд. Я это и предлагал.
А вот если вы начисляете бонусы за оплаченный заказ в отдельном сервисе слушателе, то это не есть хорошо. Это пример размазывания бизнес логики по проекту, что часто встречается при использовании событийно-ориентированного подхода.
Скорей: начисление бонусов рефералу за создание заказа.
Пересчет делается в сущности реферала, а вот инициировать процедуру начисления бонусов можно через заказ.
Согласен с Fesor. Очень трудно говорить не зная особенностей бизнеса.
Например мне не понятно почему вы не можете пересчитывать бонусные баллы реферала дважды?
Они пересчитываются по разным событиям и количество начисляемых баллов может, а скорей всего и будет, различаться. Также хорошо бы сохранить в истории начисления баллов за что их начисляли каждый раз. То есть опять же нужно сохранять их раздельно.
По идее, вам надо по каждому событию от заказа пересчитывать баллы рефералов и генерить событие обновления счета, их агрегировать и отправлять рефералу уведомление с подробным отчётом за что и сколько он получил баллов.
Да. И не только. Например для соблюдения SRP, часть кода можно вынести в обработчик событий, но чтоб не размазывать бизнес логику по проекту, её можно сохранить в сущности.
Например, тот же пример от Fantyk можно решить через обработку событий в сущности заказа.
Я в это случае создаю CQRS команду на отправку SMS уведомления на каждое событие и кладу ее в очередь уникальных команд и по крону разбираю очередь.
Это даёт нам и сохранение уникальности уведомлений и позволяет не тормозить клиент на отправку SMS и контролировать нагрузку на сервер отправки SMS.
Добавлю и свою либу
https://github.com/gpslab/domain-event
бандл для интеграции с Symfony
https://github.com/gpslab/domain-event-bundle
Кроме стандартного агрегирования событий ещё позволяет обрабатывать события в самой сущности, имеет функционал для реализации слушателей, подписчиков, очередей и middleware
Тут я полностью поддерживаю. Под новые проекты стараюсь писать свои админки заточенные под конкретный проект.
Ну если прям для савсем савсем простых CRUD проектов которые не планируют развивается, то да. Сгодится. Правда я с такими проектами не работаю.
Мои проекты либо сразу сложнее, либо гарантированно будут усложняется и тогда внедрение сонаты только время сэкономит.
Спасибо за ссылку.
Не знал про EasyAdminBundle.
Но похоже EasyAdminBundle ещё больше завязан на антипаттерне Anemic model, чем SonataAdminBundle.
И конфигурирование форм в yaml файлах попахивает чем-то.
И не понятно как использовать свои FormType