Comments 26
Великолепнейший образчик животного земли, успешно развивающееся на протяжении 50 000 000 лет и какой-то 30ти-летний человечишка со своими глобальными мыслями об очередной нашей локальной фигнёй, о которой завтра забудут (при всём уважении).
За китов вот сейчас было обидно, да...
Это я не к тому, что в результатах эволюции нельзя ничего улучшить (можно), а о том, что не стоит бездумно пытаться квалифицировать эволюционные особенности.
Хммм, значит ли это
Нет. Попробуйте прочитать верхний пост внимательнее.
Нужно выкатить свой экземпляр, а уже потом можно что-то говорить. Верно? Вы же это имели ввиду?)
Для меня странно слышать слово "дефект" от тех, кто без доступа к тому же киту и тому, из чего он состоит и как работает — вообще ничего не может.
Это как поколение, которому полностью начхать на своих родителей, если они не умеют в айфончик пальцем тыкать.
Акулы охотятся на китов в том числе не давая им всплыть, чтобы подышать. Это лучше?
Пара замечаний по неудачному дизайна кита.
- Кит большой. Сжигает много пищи и кислорода.
- В воде содержание растворённого кислорода достигает 11 см³ на литр. В воздухе содержание кислорода равно 210 см³ на литр.
- Для получения достаточного количества кислорода из воды нужно прокачивать через жабры большие её количества. Например, непрерывно двигаясь (как акулы). И еще больше увеличивая потребление кислорода.
- Кит теплокровен — его подвижность не зависит от температуры. Большинство видов акул — нет. Для подогрева тела киту опять же нужны пища и кислород.
- Для того, чтобы получить достаточное количество еды, крупной рыбы уже недостаточно. Как и крупнейшие виды акул, киты питаются планктоном. И рады бы рыбкой, да где ж её взять в таких количествах?
- Киты были замечены на глубине до 3 километров. Акулы — до двух.
Возможно, MVP акулы и выглядит перспективнее, но мне кажется, что с ростом проекта разработчикам пришлось внести коррективы в то, что поначалу казалось таким очевидным.
Для получения достаточного количества кислорода из воды нужно прокачивать через жабры большие её количества. Например, непрерывно двигаясь (как акулы). И еще больше увеличивая потребление кислорода.
где у кита жабры? Если это млекопитающее, то у него легкие (sic!)
Кит теплокровен — его подвижность не зависит от температуры. Большинство видов акул — нет. Для подогрева тела киту опять же нужны пища и кислород.
Не понял — где тут неудачный дизайн? Лучше же быть подвижным, чем нет? Не так ли ?
где у кита жабры? Если это млекопитающее, то у него легкие (sic!)
Комментарий относится к первым двум абзацам статьи, где анализируется дизайн кита.
В них автор статьи приходит к выводу что дизайн — ужасен, потому что кит — не рыба. А еще кит — не хищник и вообще легаси. И нужно все переписать.
При том, что пятиминутного изучения domain'а (предметной области) должно было бы, чтобы понять, что рыба размером с кита просто задохнется. А хищник такого размера — умрет голодной смертью.
Не уверен, что для мелких и средних проектов такой подход будет выгодным. Для больших — может быть…
Пример с сигналами Django не лучший, не уверен, что ими хоть кто-то сейчас активно пользуется. Не назвал бы их ни удобными, ни безопасными.
В то же время, некоторые идеи вполне полезны сами по себе. Например, «константный» контекст и его наполнение, сам пришёл к чему-то подобному.
У подобного «основательного» подхода к разработке основные плюсы сосредоточены на этапе поддержки/сопровождения, на это и надо делать упор в рассказе. Добавить больше генерации чего-нибудь, рисования диаграм, автоматического рефакторинга.
В текущем варианте — overengineering в чистом виде.
Техническая часть статьи сводится к тому, как силами всего трех дополнительных модулей и нескольких подключенных библиотек в Django-приложение можно встроить декларативный язык для описания stories. И что это дает некоторые преимущества при отладке бизнес-логики.
Сама реализация, ограничения, которые она накладывает на оптимизацию, технические проблемы, которые придется решать, полностью аналогичны тем, что встречаются при реализации GraphQL-сервера.
Сейчас, судя по приведенному коду, возможные проблемы не решаются никак.
Более того — решить их на уровне библиотеки так, чтобы разработчик мог сконцентрироваться на бизнес-логике, в текущей, синхронной, версии Django не получится.
Так все правильно — все бизнес-проекты скатываются в легаси, потому что бизнес давит, что фичи нужны вчера, старая команда рассасывается кто куда и все… до DDD уже дело не доходит )
На небольших это как раз overengineering как правильно подметили в комментарии выше.
DDD != архитектура, DDD не учит писать поддерживаемый с технической точки зрения код.
И техническая сложность никуда не пропадёт, если фокусироваться лишь на естественной сложности доменной области, к тому же на ней сфокусироваться вряд ли получится, пока есть проблемы с технической стороны.
А автор, именно что, пытается уменшать сложность техническую через DDD, ничего дельного из этого не выйдет.
Под видом DDD делать агрегаты и сущности data-классами(то есть анемичную модель) — серьёзно?
Здесь мы указываем задачу взять в пакете services класс, поместить в него три mappers, проинициализировать объект Stories и отдать нам.
Я правильно понимаю, что по мнению автора, это понятная для менеджеров без технической экспертизы фраза(единый язык)?
Инструменты Domain Driven Design