Хороший, плохой и эффективный дизайн
Зачастую разработчики не думают об архитектуре, точнее, формируют дизайн “по запросу” по мере того, как выполняют технические задачи из бэклога. Это происходит тогда, когда Scrum используется для контроля за сроками поставки, а не со своей первоначальной целью приобретения знаний о системе и предметной области.
Проблемы, которые можно решить с помощью DDD от высокоуровневых бизнесовым к техническим:
- Разработка ПО рассматривается как центр затрат, а не как центр прибыли. Бизнес зачастую не рассматривает ИТ как стратегическое конкурентное преимущество
- Разработчики слишком зациклены на технологиях и пытаются решать задачи с помощью технологий, а не вдумчивого анализа и планирования.
- Базам данных уделяется слишком много внимания, и большая часть проектирования заключена в подготовке модели данных.
- Разработчики не стремятся именовать объекты и операции в соответствии с их бизнес-смыслом. Это приводит к расхождению в ментальных моделях бизнеса и разработчиков.
- Слабая коммуникация разработчиков с бизнесом.
- Слишком часто запрашиваются оценки состояния проекта, порядок фич меняется, и это приводит к фича-потоку без вдумчивого анализа и проектирования.
- Разработчики зачастую помещают бизнес-логику в слой пользовательского интерфейса или слой базы данных. Более того, часто операции сохранения выполняются в середине выполнения бизнес-логики.
- Существуют сломанные, медленные или блокирующие запросы к базам данных, из-за которых невозможно осуществлять чувствительные ко времени операции.
- Существуют неверные абстракции 99 бутылок ООП, которые затрудняют выведение верных. К тому же неверные абстракции могут выливаться в перепроектирование и нарушения принципа YAGNI.
- Существуют сильно зацепленные (coupled) службы, которые образуют хрупкую цепочку вызовов.
Важно понимать, что проектирование все равно происходит, даже если на эту активность явно не выделяется время. Проектирование неизбежно. Альтернатива хорошему дизайну - это плохой дизайн, а не его отсутствие.
Приобретение знаний в Scrum имеет смысл “покупки”, т.е. знания не бесплатны. Для их получения необходимо потратить время на совместное обучение и эксперименты с моделями и кодом.