Для всех интересующихся чистой архитектурой и DDD могу посоветовать посмотреть на проект dry-python — набор библиотек для написания сложных бизнес приложений.
Отдельное спасибо автору статьи за упоминание нашего проекта dry-python (https://github.com/dry-python).
В статье действительно хорошо описаны проблемы жёстких зависимостей между разными частями кода.
Причём чем больше кодовая база — тем больнее их решать.
Проект dry-python это не только dependency injection, но и набор библиотек для построения Clean Architecture и Domain-Driven Design. Есть библиотеки для слоя сервисов (stories и returns), есть библиотеки для слоя репозиториев (mappers).
Хочу дополнительно осветить причины по которым мы выбрали dependency injection вместо service locator в виде глобального дикта.
1. Допустим есть два класса PlaceOrder и FinishOrder из сервисного слоя.
2. Они оба зависят от GLOBAL_DICT['SmsGateway'].
3. Через некоторое время понадобится поменять детали отправки sms'ок в FinishOrder для пользователей из страны Х.
4. Понадобится поправить код и FinishOrder и GLOBAL_DICT.
В то время как при использовании DI понадобится поправить только контейнер FinishOrderInjector. К тому же детали, такие как «активный залогиненный пользователь» будет проще через DI прокинуть, чем через весь стек вызовов. В FinishOrder, например, этого пользователя может и не быть.
Если вдруг кого-то заинтересовал проект dry-python — можно посмотреть больше видео тут dry-python.org/talks
Очень порадовал доклад про поддержку большого проекта на Django 10000 коммитов спустя.
Гексагональная архитектура Кокбёрна и Чистая архитектура Мартина очень крутые и массивные штуки.
Что Django, что Flask, не дают никаких инструментов для их построения.
В итоге все доклады (включая мой 2015 года) скатываются в изобретение этих инструментов средствами выбранного фреймворка.
Как раз чтобы решить эту проблему начал писать проект dry-python.org
Это набор небольших инструментов для построения высокоуровневой архитектуры приложения. Проект ставит целью дать ответы на вопрос «Как грамотно декомпозировать и реализовать бизнес задачу.»
Например, описывать Юзкейсы можно декларативным DSL. Из него растет продвинутая интеграция с Sentry, Pytest и Debug ToolBar stories.readthedocs.io/en/latest/why.html
Отделить реализацию от бизнес логики можно с помощью Dependency Injection. Из плюсов опять же интеграция с Django, Flask, Celery и Pytest. dependencies.readthedocs.io/en/latest/why.html
Есть проект на Django с примером реализации небольшого магазина, реализованный на утилитах dry-python github.com/dry-python/tutorials
Думаю будет полезно для людей, которые хотят у себя в проекте грамотно организовать слой сервисов.
Java машина безотносительно любого фреймворка стартует сильно дольше. Плохой платформой это её ещё не делает. Можно где-то посмотреть сравнение времени старта с SQLAlchemy, Peewee и Orator на том же количестве моделей? О каком наборе моделей вообще идёт речь?
Говорите как фанат чего-то другого. Все фронтенд технологии, кроме изоморфного подхода, прекрасно будут жить рядом с Django. Дельные инновации как раз таки портируются не только на питон и погоду делают в целом везде.
Тяжело будет оправдывать Django без конкретных примеров критики, но я попробую предположить.
1. Django это не про SPA.
Сейчас наверное большая часть приложений пишется с каким-нибудь frontend фреймворком. Например, Angular, React или Vue. Django по умолчанию предлагает нам относительно медленный язык шаблонов, которые обрабатываются на сервере. Во-первых, можно взять Django Rest Framework (отдельный пакет) и Django будет отличным API сервисом backend для вашего SPA приложения. Во-вторых, если шаблонов на сервере достаточно для сложности приложения, но не устраивает скорость, можно взять Jinja2, который поддерживается из коробки. Он быстрый в силу компиляции в python bytecode.
2. Django это не про WebSockets.
Опять же огромное количество приложений хотят живой контент без постоянного хождения на сервер по HTTP. Уже несколько лет Django поддерживает Websockets и HTTP2 протоколы с помощью официального расширения Django Channels.
3. Django плохо масштабируется.
На самом деле у Django есть db router, который позволяет горизонтально масштабировать базу данных. Например, пользователей от А до Е и всё что с ними связано мы будет хранить на одном сервере, остальных на другом. У нас есть программный интерфейс чтобы этим самим управлять. Тоже самое есть для слоя кэширования.
Из хорошего от себя могу сказать что это фреймворк с адекватным project management. Есть LTS версии. Исправления безопасности выходят для нескольких актуальных версий сразу. Есть ясный и понятный процесс принятия нововведений Django Enhancement Proporans.
Для всех интересующихся чистой архитектурой и DDD могу посоветовать посмотреть на проект dry-python — набор библиотек для написания сложных бизнес приложений.
Пример как это выглядит на живом репозитории: github.com/dry-python/bookshelf
Доклад clean architecture для django приложений: www.youtube.com/watch?v=tKEv9Enhm1Q
На небольших это как раз overengineering как правильно подметили в комментарии выше.
Отдельное спасибо автору статьи за упоминание нашего проекта dry-python (https://github.com/dry-python).
В статье действительно хорошо описаны проблемы жёстких зависимостей между разными частями кода.
Причём чем больше кодовая база — тем больнее их решать.
Проект dry-python это не только dependency injection, но и набор библиотек для построения Clean Architecture и Domain-Driven Design. Есть библиотеки для слоя сервисов (stories и returns), есть библиотеки для слоя репозиториев (mappers).
Хочу дополнительно осветить причины по которым мы выбрали dependency injection вместо service locator в виде глобального дикта.
1. Допустим есть два класса PlaceOrder и FinishOrder из сервисного слоя.
2. Они оба зависят от GLOBAL_DICT['SmsGateway'].
3. Через некоторое время понадобится поменять детали отправки sms'ок в FinishOrder для пользователей из страны Х.
4. Понадобится поправить код и FinishOrder и GLOBAL_DICT.
В то время как при использовании DI понадобится поправить только контейнер FinishOrderInjector. К тому же детали, такие как «активный залогиненный пользователь» будет проще через DI прокинуть, чем через весь стек вызовов. В FinishOrder, например, этого пользователя может и не быть.
Если вдруг кого-то заинтересовал проект dry-python — можно посмотреть больше видео тут dry-python.org/talks
Очень порадовал доклад про поддержку большого проекта на Django 10000 коммитов спустя.
Гексагональная архитектура Кокбёрна и Чистая архитектура Мартина очень крутые и массивные штуки.
Что Django, что Flask, не дают никаких инструментов для их построения.
В итоге все доклады (включая мой 2015 года) скатываются в изобретение этих инструментов средствами выбранного фреймворка.
Как раз чтобы решить эту проблему начал писать проект dry-python.org
Это набор небольших инструментов для построения высокоуровневой архитектуры приложения. Проект ставит целью дать ответы на вопрос «Как грамотно декомпозировать и реализовать бизнес задачу.»
Например, описывать Юзкейсы можно декларативным DSL. Из него растет продвинутая интеграция с Sentry, Pytest и Debug ToolBar stories.readthedocs.io/en/latest/why.html
Отделить реализацию от бизнес логики можно с помощью Dependency Injection. Из плюсов опять же интеграция с Django, Flask, Celery и Pytest. dependencies.readthedocs.io/en/latest/why.html
Есть проект на Django с примером реализации небольшого магазина, реализованный на утилитах dry-python github.com/dry-python/tutorials
Думаю будет полезно для людей, которые хотят у себя в проекте грамотно организовать слой сервисов.
cc danilovmy dimuska139 valis
Из последнего есть подкаст исключительно о Django: djangochat.com
1. Django это не про SPA.
Сейчас наверное большая часть приложений пишется с каким-нибудь frontend фреймворком. Например, Angular, React или Vue. Django по умолчанию предлагает нам относительно медленный язык шаблонов, которые обрабатываются на сервере. Во-первых, можно взять Django Rest Framework (отдельный пакет) и Django будет отличным API сервисом backend для вашего SPA приложения. Во-вторых, если шаблонов на сервере достаточно для сложности приложения, но не устраивает скорость, можно взять Jinja2, который поддерживается из коробки. Он быстрый в силу компиляции в python bytecode.
2. Django это не про WebSockets.
Опять же огромное количество приложений хотят живой контент без постоянного хождения на сервер по HTTP. Уже несколько лет Django поддерживает Websockets и HTTP2 протоколы с помощью официального расширения Django Channels.
3. Django плохо масштабируется.
На самом деле у Django есть db router, который позволяет горизонтально масштабировать базу данных. Например, пользователей от А до Е и всё что с ними связано мы будет хранить на одном сервере, остальных на другом. У нас есть программный интерфейс чтобы этим самим управлять. Тоже самое есть для слоя кэширования.
Из хорошего от себя могу сказать что это фреймворк с адекватным project management. Есть LTS версии. Исправления безопасности выходят для нескольких актуальных версий сразу. Есть ясный и понятный процесс принятия нововведений Django Enhancement Proporans.
Надеюсь сумел угадать мифы.