#architecture #mvc

PHP сегодня — это не просто формочки да работа с базой данных. Это архитектура, паттерны и множество лучших практик создания приложения на данном языке. В этих двух статьях раскрываются самые популярные принципы создания приложений на PHP:

https://bit.ly/2PxYrfw

https://bit.ly/2QUH59j

#advanced

Кто любит архитектуру приложений, как мы, могут посмотреть следующий большой плейлист различных видео по самым разным и полезным темам ООП в PHP.

https://github.com/phptodayorg/php-must-watch#architecture-and-design

#advanced #architecture

Кроме устоявшегося уже SOLID, есть еще группа шаблонов для решения проблем, связанных с распределением ответственности между объектами, собранных под общим названием GRASP. Одни из самых интересных - это coupling и cohesion, которые определяют связи между функциональными модулями одного приложения. Подробнее по ссылке:

https://proglib.io/w/04aa1f02

#advanced #architecture

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

https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c

#architecture

Когда возникает вопрос о том, чтобы наша бизнес-сущность имела различные состояния, мы создаем у сущности поле state/status, которое помогает ориентироваться в том, как управлять сущностью и какие операции допустимы. Такой подход кажется не совсем удобным, когда бизнес-операции имеют важное значение в разное время жизни сущности. Во-первых, дублирование каких-то действий, если вы забыли проверить текущий статус, может сломать состояние модели (что если заказ будет оплачен 2 раза?). Во-вторых, у разных состояний разный набор бизнес-операций, а иногда – разный набор данных: где-то больше, где-то меньше. Было бы удобнее не держать все в одном месте, а делать на каждый статус отдельную таблицу. К сожалению, если вы не используете совместно с таким подходом CQRS, вам будет сложно работать с такой структурой при выборках данных. Есть и другой подход – отдельная таблица со статусами. Подробнее можно почитать по ссылке: https://dba.stackexchange.com/questions/158949/should-i-create-multiple-tables-for-different-entity-states-statuses-or-stages.

А расскажите про свой опыт управления сущностями с разными статусами в комментариях.

#advanced #architecture

Большая статья, в которой рассматриваются примеры технологий и подходов при построении высоконагруженных приложений:

1. Балансировщики нагрузки;
2. SQL или NoSQL базы данных;
3. Шардинг;
4. Репликация;
5. Кэширование;
6. CDN;
7. Long-polling vs Websockets vs SSE.

https://proglib.io/w/4bc624df

#advanced #architecture

Хорошая статья с многочисленными выдержками из книг и статей на тему управления логикой приложения и проектированию сервисного слоя, Use Case, CQRS, Event Sourcing и др.

https://emacsway.github.io/ru/service-layer/

#advanced #architecture

"DRY – это про знания. Дублирование кода – это не проблема", – так эту статью начинает Матьяс Верраес. Статья рассказывает о том, о чем на самом деле говорит принцип "Don't repeat yourself".

https://verraes.net/2014/08/dry-is-about-knowledge/

#advanced #architecture

Frank De Jonge, автор Flysystem, рассказывает о том, какие типы событий бывают в event-driven системах.

https://blog.frankdejonge.nl/the-different-types-of-events-in-event-driven-systems/