Продолжение про «похожие процессы» и про важность DDD.
(кажется, получился очень глубокий и важный пост про важность DDD)
Конкретным профессиям и их внутренней кухне (туризму, логистике, финансам, медицине) в профильных вузах учат годами. Для тех, кто прошел такой путь, типовые процессы внутри их отрасли выглядят очень похожими: одни и те же шаги, одни и те же риски, одни и те же точки принятия решений. Но есть один нюанс…
Взять сферу туризма – это отдельная профессия, ей учатся по пять лет, чтобы нормально разбираться в маршрутах, сезонах, рисках, партнерах и ожиданиях клиентов. И взять разработчика – тоже лет пять только чтобы уверенно писать код, понимать архитектуру, паттерны, инфраструктуру.
И вот спец по туризму открывает турфирму. Нанимает сотрудников, поднимает продажи, строит партнерства – бизнес как‑то работает.
В какой‑то момент становится тесно в Excel и мессенджерах и он нанимает разработчиков: «пора автоматизировать».
Что разработчик, который 5 лет учился на разработчика, знает о туризме? Ну… есть Турция, Египет, самолетом можно долететь, отели бывают с завтраком и без….
У него нет такого же целостного и глубокого представления о процессе, как у эксперта в туризме. Прилетает задача: «сделай бронь места в гостинице, вот тут предоплата, вот тут подтверждение». Он честно реализует эту отдельную фичу.
Потом еще одну.
Потом «быструю доработку к сезону».
Потом срочный костыль «потому что партнер меняет правила».
Со временем разработчик, конечно, начинает лучше понимать процесс, картинка становится целостнее…. но к этому моменту система уже обросла заплатками так, что ее страшно трогать. «Сначала требования определяют архитектуру, а затем живут в ней» (c) мой
И вот в системе сотня мест, где бизнес-жвачка намотана на технический долг и любая попытка рефакторинга превращается в операцию на сердце.
С должным усилием, упорством и желанием этот разработчик вырастает до архитектора.
Он наконец смотрит на весь процесс целиком и понимает, что 90% кода можно выбросить и заменить несколькими коробочными продуктами, одним внешним сервисом и небольшим слоем кастома. Потому что реально уникальное – вот эти самые 5%, где и прячется конкурентное преимущество бизнеса, а все остальное – типовой, стандартный Generic.
Вот эту проблему во многом и решает DDD вместе с практиками вроде Event Storming.
Они как раз про то, как вытащить знание экспертов (в нашем примере – гуру в туризме), перевести его в общий язык и донести до разработчиков и архитекторов так, чтобы все видели одну и ту же цельную картину.
Пока этого понимания нет, «в прод идут лишь предположения разработчиков о предметной области» (c) Альберто Брандолини
Как только оно появляется – архитектура начинает работать на бизнес, а не наоборот.
(кажется, получился очень глубокий и важный пост про важность DDD)
Конкретным профессиям и их внутренней кухне (туризму, логистике, финансам, медицине) в профильных вузах учат годами. Для тех, кто прошел такой путь, типовые процессы внутри их отрасли выглядят очень похожими: одни и те же шаги, одни и те же риски, одни и те же точки принятия решений. Но есть один нюанс…
Взять сферу туризма – это отдельная профессия, ей учатся по пять лет, чтобы нормально разбираться в маршрутах, сезонах, рисках, партнерах и ожиданиях клиентов. И взять разработчика – тоже лет пять только чтобы уверенно писать код, понимать архитектуру, паттерны, инфраструктуру.
И вот спец по туризму открывает турфирму. Нанимает сотрудников, поднимает продажи, строит партнерства – бизнес как‑то работает.
В какой‑то момент становится тесно в Excel и мессенджерах и он нанимает разработчиков: «пора автоматизировать».
Что разработчик, который 5 лет учился на разработчика, знает о туризме? Ну… есть Турция, Египет, самолетом можно долететь, отели бывают с завтраком и без….
У него нет такого же целостного и глубокого представления о процессе, как у эксперта в туризме. Прилетает задача: «сделай бронь места в гостинице, вот тут предоплата, вот тут подтверждение». Он честно реализует эту отдельную фичу.
Потом еще одну.
Потом «быструю доработку к сезону».
Потом срочный костыль «потому что партнер меняет правила».
Со временем разработчик, конечно, начинает лучше понимать процесс, картинка становится целостнее…. но к этому моменту система уже обросла заплатками так, что ее страшно трогать. «Сначала требования определяют архитектуру, а затем живут в ней» (c) мой
И вот в системе сотня мест, где бизнес-жвачка намотана на технический долг и любая попытка рефакторинга превращается в операцию на сердце.
С должным усилием, упорством и желанием этот разработчик вырастает до архитектора.
Он наконец смотрит на весь процесс целиком и понимает, что 90% кода можно выбросить и заменить несколькими коробочными продуктами, одним внешним сервисом и небольшим слоем кастома. Потому что реально уникальное – вот эти самые 5%, где и прячется конкурентное преимущество бизнеса, а все остальное – типовой, стандартный Generic.
Вот эту проблему во многом и решает DDD вместе с практиками вроде Event Storming.
Они как раз про то, как вытащить знание экспертов (в нашем примере – гуру в туризме), перевести его в общий язык и донести до разработчиков и архитекторов так, чтобы все видели одну и ту же цельную картину.
Пока этого понимания нет, «в прод идут лишь предположения разработчиков о предметной области» (c) Альберто Брандолини
Как только оно появляется – архитектура начинает работать на бизнес, а не наоборот.