Довольно сумбурная практическая часть. Ещё и выглядит со стороны, как своего рода каргокульт. Для такого простого юзкейса накручивать интерфейсы, абстракции и прочие DDD - оверинжинирг. Было бы нагляднее взять действительно сложный код вместо crud и на нем поработать. А потом спросить, насколько надо вертеть подобное для суперпростых кейсов. И почему иногда лучше юзать transaction script или active record
идея задачи была не в том, чтобы для простейшего фласк приложения навернуть DDD и приправить чистой архитектурой, а просто, в общем и целом, показать как можно "почистить" архитектуру - то есть на понимание слоев, архитектурных границ, и стрелки зависимостей.
40:17 чтобы переписать животных на композицию их всего-то нужно декомпозировать. То бишь для того, чтобы животное ело, можно не делать для него метод есть(), а создать сущности, из которых состоит тигр и, соотетственно, разные части тигра будут выполнять разные функции. В частности за поглощение пищи будет отвечать хлеборезка (whatever)... А декомпозиция самого зоопарка -- это более высокоуровневая фигня.
Возможно я не понимаю что нужно знать СНГ кодеру, но слушать о DRY, композиции вс наследования, "Чистой архитектуры" и интерфейсах звучит максимально некомпетентно. такие штуки должен знать человек с 1 годом опыта и то понимать что это даже не в тройке важных знаний. Где структуры данных, database internals, OS internals, networking(хотябы базовый), language internals and so on. Если реальные собеседования похожи на эту мок версию то мне кажется это и печально и хорошо. Конечно хорошо для более опытных так как конкуренция ниже. Почему именно такое собеседование? Буду рад получить ответ.
