Миксин это сущность примерно такого же порядка как функция или класс, сами по себе они никакой ценности для бизнес-логики не несут. Не совсем понимаю как вы в данном контексте себе представляете их. Но сходу могу сказать что миксины часто приводят ко множественному наследованию, которое в целом можно назвать плохой практикой - я уверен что нету программистов, которым доставляло бы удовольствие сидеть на работе и высчитывать mro, чтобы понять как пофиксить очередной баг.
Благодарю! Пакетов таких много, как я писал в статье. Даже у гугла есть свой. Отношение к подобному я выразил выше - подумайте, нужно ли вам строить свою бизнес-логику вокруг сторонней зависимости. Библиотеки не определяют бизнес-логику, это всего лишь инструменты, которые бизнес-логика должна использовать в своих целях. К инструментам должно быть отношение как к инструментам - их сотни, каждый год выходят все более красивые и эффективные. От них не нужно зависеть - устаревшие и малоэффективные надо выбрасывать, брать более стабильные и совершенные. Сможете ли вы с легкостью выкинуть вашу библиотеку, и поменять на новую, не тронув при этом бизнес-логику? Сомневаюсь. Сложно ли это будет сделать, если ваш проект будет разрабатывать команда, скажем, из человек 10-50, а не один вы? Да, наверное. Можете ли вы однажды упереться в ограничения заложенные автором бибилиотеки? Думаю да, особенно если ваш сервис станет действительно большим и многофункциональным. Сервисный слой, это прежде всего часть философии слоистой архитектуры, в центре которой лежит домен и его бизнес-логика, а внешние библиотеки это уже дело десятое.
Основная польза от паттерна Command это то, что команды не возвращают значения, а значит их нельзя объединять в цепочки
С чего вы взяли? Достаточно пройти в гугл с запросом "command pattern return value", чтобы быстро убедиться что это не так. В любом случае, кто и как бы не давал определения паттернам, важно помнить что они не на скрижалях высечены, и адаптировать их для своих потребностей разработчики вольны как хотят.
Привет, спасибо за отзыв! Нет, не перевод. То что вы пишите имеет место быть, но статья тут скорее про совсем базовые принципы, которые были выстраданы на основе опыта поддержки и развития именно бизнес-логики, огромного и старого Django-монолита на протяжении последних пяти лет моей работы, поэтому старался максимально уйти от всяких нюансов самого фреймворка, типа менеджеров моделей, класса Storage и тп. То что сервис с выдачей "имен" вообще не должен знать о моделях Django действительно верно, но в моей парадигме это уже следующий этап развития, и движение в сторону DDD и Clean Architecture, которые, на моем опыте, подразумевают под собой больше телодвижений, дисциплины в команде, и некий порог вхождения. Может, когда нибудь выпущу статью про опыт реализации и поддержки проекта на основе Clean Architecture на питоне.
Миксин это сущность примерно такого же порядка как функция или класс, сами по себе они никакой ценности для бизнес-логики не несут. Не совсем понимаю как вы в данном контексте себе представляете их. Но сходу могу сказать что миксины часто приводят ко множественному наследованию, которое в целом можно назвать плохой практикой - я уверен что нету программистов, которым доставляло бы удовольствие сидеть на работе и высчитывать mro, чтобы понять как пофиксить очередной баг.
Благодарю! Пакетов таких много, как я писал в статье. Даже у гугла есть свой. Отношение к подобному я выразил выше - подумайте, нужно ли вам строить свою бизнес-логику вокруг сторонней зависимости. Библиотеки не определяют бизнес-логику, это всего лишь инструменты, которые бизнес-логика должна использовать в своих целях. К инструментам должно быть отношение как к инструментам - их сотни, каждый год выходят все более красивые и эффективные. От них не нужно зависеть - устаревшие и малоэффективные надо выбрасывать, брать более стабильные и совершенные. Сможете ли вы с легкостью выкинуть вашу библиотеку, и поменять на новую, не тронув при этом бизнес-логику? Сомневаюсь. Сложно ли это будет сделать, если ваш проект будет разрабатывать команда, скажем, из человек 10-50, а не один вы? Да, наверное. Можете ли вы однажды упереться в ограничения заложенные автором бибилиотеки? Думаю да, особенно если ваш сервис станет действительно большим и многофункциональным. Сервисный слой, это прежде всего часть философии слоистой архитектуры, в центре которой лежит домен и его бизнес-логика, а внешние библиотеки это уже дело десятое.
С чего вы взяли? Достаточно пройти в гугл с запросом "command pattern return value", чтобы быстро убедиться что это не так. В любом случае, кто и как бы не давал определения паттернам, важно помнить что они не на скрижалях высечены, и адаптировать их для своих потребностей разработчики вольны как хотят.
Благодарю!
Привет, спасибо за отзыв! Нет, не перевод. То что вы пишите имеет место быть, но статья тут скорее про совсем базовые принципы, которые были выстраданы на основе опыта поддержки и развития именно бизнес-логики, огромного и старого Django-монолита на протяжении последних пяти лет моей работы, поэтому старался максимально уйти от всяких нюансов самого фреймворка, типа менеджеров моделей, класса Storage и тп. То что сервис с выдачей "имен" вообще не должен знать о моделях Django действительно верно, но в моей парадигме это уже следующий этап развития, и движение в сторону DDD и Clean Architecture, которые, на моем опыте, подразумевают под собой больше телодвижений, дисциплины в команде, и некий порог вхождения. Может, когда нибудь выпущу статью про опыт реализации и поддержки проекта на основе Clean Architecture на питоне.