📛
Один инженер сказал недавно:
«Я скучаю по временам, когда разработчики разбирались в том, что проектирует от и до. Сейчас много Spring программистов»Разбираться в предметной области для меня всегда было нормой.
Собрал этапы трансформации походов к проектированию.
- 70-ые Разработчик – разбирается в предметной области.
- 80-ые Разработчик пишет код, который соответствует постановке. (водопад)
- 2003 Разработчик – эксперт предметной области
В индустрии трансформация происходит с лагом. В 201X корпорации начинают меняться. Одни немного раньше, другие только сейчас в 2000х.
Эффективное цифровое производство – актуальная тема.
Цитата:
Domain-Driven Design: The First 15 Years. 172. Enhancing DDD — Prof. David West
В начале 1970-х годов идеи и методы «структурированного анализа и проектирования» (SAD) доминировали в практике разработки программного обеспечения. SAD пропагандировал:
• Шаг первый: смоделируйте предметную область
• Шаг второй: определите, какие изменения вы хотели бы улучшить или исправить проблемы в предметной области.
• Шаг третий: проведите мозговой штурм нескольких способов, которыми изменения могут быть затронуты.
• Шаг четвертый: проанализируйте, какое «решение» является оптимальным.
• Шаг пятый: смоделируйте выбранное решение, включая модуляризацию программного обеспечения.
• Шаг шестой: внедрите модель.
• Шаг седьмой: разверните и оцените внедренное решение и его влияние на предметную область
Редко, если вообще когда-либо, шаги с первого по четвертый фактически выполнялись. Отчасти потому, что руководство бизнеса не видело ценности и не поощряло или запрещало их как «пустую трату времени».
К середине 1970-х годов предметная область умерла.
В те же годы набирал свои обороты Водопад 🔥
Цитаты из https://en.wikipedia.org/wiki/Waterfall_model
«Хотя термин «водопад» не используется в статье, первая формальная подробная схема процесса, позже известная как «водопадная модель», часто[7] цитируется как статья Уинстона В. Ройса 1970 года.[8][9][10]»
Ройс никогда не рекомендовал и не описывал каскадную модель,[16] он критикует жесткое соблюдение следующих фаз:
- Требования к системе и программному обеспечению: зафиксированы в документе с требованиями к продукту
- Анализ: приводит к моделям, схеме и бизнес-правилам
- Проектирование: приводит к архитектуре программного обеспечения
- Кодирование: разработка, проверка и интеграция программного обеспечения
- Тестирование: систематическое обнаружение и устранение дефектов
- Операции: установка, миграция, поддержка и обслуживание полных систем
Сложно. Дорого. Не везде уместно. В армии Да. За большие деньги тоже можно. (нет)
В 2003 году Эрик Эванс поднял важную тему и прекрасно описал ее в книге в первых главах.
Почитай.
На мой взгляд разработчики упускают именно эту важную идею DDD в погоне за паттернами, принципами, кодописью и фрэйм мать их ворками.
Цитата из эссе Prof. David West:
Удивительная вещь в DDD была не в шаблонах или практиках, а в том, как тихо она опровергала основные принципы разработки программного обеспечения: ложь о том, что программистам не нужно было понимать предметные области, что все, что им нужно было знать, было набором требований, которым код должен удовлетворять!
Domain-Driven Design: The First 15 Years. 172. Enhancing DDD — Prof. David West
Эрик Эванс четко написал, что если разработчик не проектирует процесс, не понимает процесс целиком, он не способен предложить эффективную архитектуру и код.
Вот почему учиться проектировать нужно начинать с джунства и приглашать на сессии проектирования мидлов, джунов и рассказывать им почему одни решения хороши своей простой, другие нет. Простоте тоже нужно обучать и обучаться.