Философия ROSS

Как видно, совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять.

Антуан де Сент-Экзюпери

Основная концепция архитектуры ROSS заключается в том, чтобы сделать процесс проектирования и рефакторинга по возможности простым и предсказуемым. Разработка ПО сама по себе расходует слишком много мыслительных ресурсов, и разработчику важно думать над бизнес-логикой, а не над «каноничностью» архитектуры. Этого легко добиться, если канонов нет вообще =)

Опираясь на 3 ключевых параметра (пластичность, тестируемость и наглядность), ROSS предлагает 4 строительных блока, различия между которыми четко определены коротким набором правил. Необходимо лишь соблюдать эти правила, а во всем остальном можно двигаться по пути наименьшего сопротивления. Конечная форма не имеет значения, если она получена эволюционным путем, т.е. доказала свою жизнеспособность.

Предлагаемый ниже список правил тоже постоянно проходит проверку эволюцией. Ненужное атрофируется, нужное полируется и совершенствуется. На данный момент свод правил выглядит так:

1. операция неделима и не имеет доступа к другим операциям (фабрике операций);
2. сценарий не имеет доступа к другим сценариям (фабрике сценариев);
3. императивный интерфейс и состояние есть только у сервисов;
4. любые манипуляции с UI выполняются через роутер;
5. покрытие Unit-тестами всей кодовой базы на 100% невозможно и бессмысленно, но нетестируемую часть можно изолировать.

ROSS — это архитектура, которая отвечает всем вызовам, возникающим при построении сложных клиентских приложений. Основным достоинством архитектуры ROSS является ее простота, которая сочетается с высокой тестируемостью, особенно на уровне интеграционных тестов. Малое количество сущностей и четко прописанные различия между ними позволяют легко определять, куда какой код добавлять и как его именовать. Обратной стороной такой простоты является необходимость в качественной документации, которая является источником правды. На основе одного лишь нейминга, без документации, т.е. контекста, становится сложно понять, почему те или иные операции или сценарии работают именно так, а не иначе. Однако следует отметить, что вложения в документацию окупаются неявно. Наличие диаграмм прецедентов, операций, и сообщений также позволяет всем участникам процесса разработки ПО (аналитикам, проектировщикам, дизайнерам, разработчикам, тестировщикам и т.д.) общаться на едином языке. В связке с ROSS диаграммы в документации дают особенно значимый эффект.