Недавно писал статью на Хабре про проектирование, с использованием DDD подхода, вот она.
Кратко о DDD:
Это комплекс подходов к проектированию, не имеющий ярко выраженного конца, за все хорошее, против всего плохого.
И ко мне пришли с запросом организовать курс по этой теме, предложение заманчивое, если бы не два но:
1) Аудитория курса - разработчики.
2) Заказчик - интерпрайз, представитель бизнеса.
Мы познакомились с заказчиком, и вот что из этого вышло:
* Разработчики - с упрощённой точки зрения, это команда, которая находится с другой стороны от линии, которая разделяет заказчиков фичи от реализованной фичи на проде.
Для упрощения, я осознанно скипаю СА, QA, ПО, ДМ и другие роли.
* Заказчики - Это команда, которая находится с другой стороны, относительно разработчиков, заказчик хочет фичи на проде максимально быстро. С учетом всех танцев в интерпрайзе, пока задача доходит до прода, сроки уже горят.
Бизнес просит научить разработчиков писать код, соблюдая DDD, но при этом он не может отказаться от своих естественных привычек доставки фичей АСАПом, а DDD — это долгий процесс проектирования, где сегодняшние договорённости могут измениться завтра из-за новых вводных. Это ведёт к бесконечным обсуждениям и сдвигам сроков.
Аллегории, интересные факты:
* Бурдж-Халифа. Её построили быстро, но не подключили к городской канализации. Бизнес получил магнит для туристов и деньги, хоть и с временным решением (вывоз нечистот машинами). Полное проектирование «по уму» отложили.
* OpenAI. Это MVP, который быстро взлетел и зарабатывает. Кодовая база — огромный монорепозиторий без единых стандартов. Решения принимали те, кто писал код, а не архитекторы. Результат — полдюжины разных библиотек для одних и тех же задач. CI падал регулярно, тесты грузились по 30 минут. Но бизнес не ждал идеальной архитектуры. Будь там DDD, продукта могло бы и не быть.
Источник.
Вывод:
* Основной вывод: Бизнес снова доказал, иногда сделать и вывезти нечистоты машинами выгоднее, чем годами проектировать идеальную канализацию.
* Второстепенный вывод: Учить разработчиков DDD в условиях, где бизнес не готов давать время на проектирование, — всё равно что отправлять повара из столовой на курсы Мишлен, чтобы он потом снова готовил кашу из топора. Знания будут не применимы.
В чём тогда смысл DDD для бизнеса, который не может ждать?
Насколько сильно нужен DDD интерпрайзу? Да и вобще кому-то?
А с заказчиком мы не сошлись по религиозным убеждениям.
Habr
#мысли #ddd
Кратко о DDD:
Это комплекс подходов к проектированию, не имеющий ярко выраженного конца, за все хорошее, против всего плохого.
И ко мне пришли с запросом организовать курс по этой теме, предложение заманчивое, если бы не два но:
1) Аудитория курса - разработчики.
2) Заказчик - интерпрайз, представитель бизнеса.
Мы познакомились с заказчиком, и вот что из этого вышло:
* Разработчики - с упрощённой точки зрения, это команда, которая находится с другой стороны от линии, которая разделяет заказчиков фичи от реализованной фичи на проде.
Для упрощения, я осознанно скипаю СА, QA, ПО, ДМ и другие роли.
* Заказчики - Это команда, которая находится с другой стороны, относительно разработчиков, заказчик хочет фичи на проде максимально быстро. С учетом всех танцев в интерпрайзе, пока задача доходит до прода, сроки уже горят.
Бизнес просит научить разработчиков писать код, соблюдая DDD, но при этом он не может отказаться от своих естественных привычек доставки фичей АСАПом, а DDD — это долгий процесс проектирования, где сегодняшние договорённости могут измениться завтра из-за новых вводных. Это ведёт к бесконечным обсуждениям и сдвигам сроков.
Аллегории, интересные факты:
* Бурдж-Халифа. Её построили быстро, но не подключили к городской канализации. Бизнес получил магнит для туристов и деньги, хоть и с временным решением (вывоз нечистот машинами). Полное проектирование «по уму» отложили.
* OpenAI. Это MVP, который быстро взлетел и зарабатывает. Кодовая база — огромный монорепозиторий без единых стандартов. Решения принимали те, кто писал код, а не архитекторы. Результат — полдюжины разных библиотек для одних и тех же задач. CI падал регулярно, тесты грузились по 30 минут. Но бизнес не ждал идеальной архитектуры. Будь там DDD, продукта могло бы и не быть.
Источник.
Вывод:
* Основной вывод: Бизнес снова доказал, иногда сделать и вывезти нечистоты машинами выгоднее, чем годами проектировать идеальную канализацию.
* Второстепенный вывод: Учить разработчиков DDD в условиях, где бизнес не готов давать время на проектирование, — всё равно что отправлять повара из столовой на курсы Мишлен, чтобы он потом снова готовил кашу из топора. Знания будут не применимы.
В чём тогда смысл DDD для бизнеса, который не может ждать?
Насколько сильно нужен DDD интерпрайзу? Да и вобще кому-то?
Habr
#мысли #ddd
👍5