Прецедент: сценарий или операция?
В парадигме ROSS работа архитектора сводится к тому, чтобы скомпилировать диаграмму деятельности, описывающую прецедент (продуктовые требования) в совокупность диаграмм проектной документации:
- диаграммы деятельности для сценариев;
- диаграммы деятельности и/или состояний для сервисов;
- диаграммы сообщений для операций.
Таким образом, прецедент не всегда 1-в-1 отображается в сценарий. Прецедент может описываться группой сценариев, а может одной-единственной операцией. Вместе с тем оба этих случая являются надежными признаками ошибок в диаграмме прецедентов.
Прецедент, состоящий из одной операции, с большой вероятностью не является самостоятельным прецедентом, т.е. не может выполняться независимо. Скорее всего, это часть или частный случай какого-то другого, более общего прецедента. Согласно аксиоме вложенности операция не может быть вызвана вне контекста какого-либо сценария, следовательно, независимый прецедент – это всегда сценарий.
Прецедент, состоящий из нескольких сценариев, с большой вероятностью недостаточно хорошо декомпозирован. Скорее всего, часть этого прецедента потребуется выполнять независимо в другом контексте. Согласно лемме 2 сценарий A не может самостоятельно вызывать сценарий B, сценарии всегда вызываются сервисами независимо. Значит, в ходе проектирования где-то пропустили прецеденты, в которых эти сценарии задействованы, либо операцию ошибочно сочли прецедентом.
В обоих случаях следует вернуться в область продуктовых требований и более тщательно проработать пользовательскую историю и ее прецеденты. Снова и снова нам придется возвращаться к диаграмме прецедентов, которая казалась такой простой на первый взгляд! Либо не возвращаться, но тогда придется завести задачу в трекер с пометкой «техдолг». Если каждый прецедент из диаграммы прецедентов отображается в свой сценарий, то такой код очень легко модифицировать при изменении продуктовых требований. Если же прецедент отображается в проектную документацию более сложным образом, например, в группу сценариев и набор методов в AppService (см. следствие А леммы 2), то оценивать и реализовывать изменения становится сложнее.
Архитектор, помни: сложность – это твой самый главный враг! Она всегда подкрадывается незаметно =)