Потому что требования «вертикальны», а решение «горизонтально». Сейчас я объясню.
Представим себя на секундочку генератором бизнес-требований. То есть, человеком, далеким, вероятно, от конкретных технологий, но близким к бизнесу. И вот он, вооруженный своими знаниями, описывает, как он собирается заработать деньги. Точнее, это он в уме все держит, а описывает то, как должен работать продукт. Например, так: вот у нас есть пользователь, и он в нашей системе может поискать отель, выбрать подходящий и забронировать его на определенный период.
Теперь мысленно перенесемся в тело аналитика. Вот он это слышит, и, конечно, в этом сценарии появляется масса вопросов. Например — как именно выбирать отель? Как именно пользователь будет бронировать, как оплачивать? Надо ли регистрировать? Как убедится, что емейл настоящий? Как убедиться, что места есть, и что двое пользователей не займут один номер? Ну и так далее. Из одного предложения получается несколько страниц описания. Но зато вроде бы теперь все понятно.
И вот, наконец, программист, а точнее архитектор, читает все это, и, наметанным взглядом, замечает, что явно у нас есть сущности Пользователя и Отеля, возможно — Каталога Отелей, есть Резервация, есть Оплата... Во всей идее ООП — это будут отдельные классы системы. Будет вот такой класс — Пользователь, а методы у него будут, например, Зарегистрироваться, Выбрать Отель, Зарезервировать, Оплатить.
...
Подвох, как обычно, в готовности к изменениям.
Дело в том, что вот эта конверсия «вертикальных» историй в «горизонтальную» архитектуру является сложной, практически творческой операцией. Как мы знаем, собрать вообще все требования в начале разработки — это непозволительная роскошь в наше быстрое, если не сказать суетное, время. Но еще важнее то, что входной набор историй будет меняться, и надо быть готовыми к изменениям. Беда в том, что нет прямой связи между историями и архитектурой, то есть изменения в историях не приводят к изменениям в архитектуре. Анализ, декомпозицию и все эти вещи, вообще говоря, придется делать заново при каждом изменении.
Теперь самое опасное: если делать проект по кусочкам из этой абстракции, а потом окажется, что ее надо переделывать, то все, что мы сделали, вероятно, придется выкинуть. Ну, конечно, в реальности не так все трагично, многое можно будет использовать. Но в общем случае — это может быть очень большая и неприятная вещь в проекте. Вплоть до того, что изменение будет стоить ТАК дорого, что приходится «подтесывать» бизнес-модель...
Комментариев нет:
Отправить комментарий