Comments 13
Спасибо за перевод, но по мне статья так себе. Имплементации автора, на мой взгляд, через чур избыточны и выглядят как натягивание совы C# на глобус Питона. Сами пилим DDD на питоне и пока никакой нужды в классах не видели, все доменные сущности, сервисы, репозитории, итд, реализованны как модули(файл с функциями) и все просто прекрасно.
Да нет, не избыточны, обычный питоний код. Проектировать через функции или через классы в Python - дело вкуса и необходимости.
Разве что интерфейсы в Python далеко не всегда делаются, но иногда тоже нужны.
Да для описания логики почти одинаково, только отступов больше и конструкторов всяких. Пляски начинаются когда все эти классы нужно использовать, тут или в ручную, или через управление зависимостями. И еще автор не использует нотации типов, и это очень плохо для DDD кармы :) .
Пляски начинаются когда все эти классы нужно использовать
Да тоже не сказать. Но тут скорее всего у вас немного другой опыт, так что спорить не буду. :)
И еще автор не использует нотации типов, и это очень плохо для DDD кармы
Это очень плохо в принципе. Нет смысла не использовать нотации типов в Python в 2022 году, если только не нужна совместимость со старыми версиями или нужно использовать какие-то интересные хаки.
А состояние объекта как храните? В глобальных переменных внутри модуля?
Интересно, может ли применение принципа разделения интерфейсов вступать в конфликт с принципом единства ответственности — например если для сохранения объекта в БД нужен перечень полей и их типов (для создания миграций), тогда получается, при расширении полей объекта придется добавлять поля в 2-х местах, что противоречит принципу S...
Принципы проектирования SOLID с примерами на Python