Теоремы ROSS

Теорема ключевых сервисов

Теорема ключевых сервисов. Доказательство

Предположим, что обращение к ключевому сервису выполняется в сценарии. Это противоречит аксиоме однородности, согласно которой в сценариях доступны только операции.

Предположим, что обращение к ключевому сервису выполняется в операции. Во-первых, снижается пластичность фабрики операций. Конструктор фабрики теперь требует на вход ключевой сервис, чтобы фабрика могла передать этот сервис в операцию. Во-вторых, снижается тестируемость операции. Доступ к интерфейсу ключевого сервиса целиком позволяет операции выполнить вызов произвольного метода этого сервиса, поэтому в тестах операции придется проверить, что операция НЕ вызывает лишние методы, не относящиеся к работе операции. В третьих, снижается наглядность операции. Ключевой сервис может запустить произвольный сценарий, поэтому без знания реализации на основе одних только сигнатур конструктора операции и её метода launch нельзя определить, что операция делает. Все вместе эти выводы противоречат второму принципу РОСС, согласно которому пластичность, тестируемость и наглядность имеют значение.

Предположим, что обращение к ключевому сервису выполняется в другом сервисе, не являющимся ключевым. Во-первых, снижается пластичность неключевого сервиса. Конструктор неключевого сервиса теперь требует на вход ключевой сервис. Во-вторых, снижается тестируемость неключевого сервиса. Доступ к интерфейсу ключевого сервиса целиком позволяет выполнить вызов произвольного метода этого сервиса. В тестах неключевого сервиса придется проверить, что он НЕ вызывает лишние методы, не относящиеся к его работе. В третьих снижается наглядность неключевого сервиса. Неключевой сервис может опосредованно через ключевой сервис запустить произвольный сценарий. Без знания реализации на основе одних только сигнатур конструктора неключевого сервиса нельзя определить, что этот сервис делает. Все вместе эти выводы противоречат второму принципу РОСС, согласно которому пластичность, тестируемость и наглядность имеют значение.

Предположим, что обращение к ключевому сервису выполнено в другом ключевом сервисе. Пластичность сохранена: контекст формирования ключевых сервисов имеет доступ ко всей необходимой инфраструктуре, включая фабрику сценариев. Тестируемость сохранена: ключевой сервис получает на вход только фабрику сценариев и, возможно, другие ключевые сервисы. Тесты описывают все возможные варианты взаимодействия между ключевыми сервисов, поскольку эти варианты непосредственно формируют бизнес-логику. Наглядность сохранена: обращения ключевого сервиса к фабрике сценариев и другим ключевым сервисом непосредственно отображаются в высокоуровневые диаграммы активности, т.е. в User Flow.

Таким образом, обращение к ключевому сервису может быть выполнено только в другом ключевом сервисе. Что и требовалось доказать.

Теорема параметризации сценариев

Теорема параметризации сценариев. Доказательство

Предположим, что операция осуществляет вызов сценария непосредственно. Это противоречит Лемме 2, согласно которой вызов сценария осуществляется в только в сервисах.

Предположим, что операция в ходе выполнения обращается к ключевому сервису, имеющему доступ к фабрике операций. Это противоречит теореме ключевых сервисов, согласно которой обращение к ключевому сервису может быть выполнено только в другом ключевом сервисе.

Предположим, что операция осуществляет вызов сценария через параметризацию метода launch, делегируя вызов внутрь другого сценария, в контексте которого она выполняется. Это противоречит Лемме 2, согласно которой вызов сценария осуществляется в только в сервисах.

Таким образом, вызов сценария может быть осуществлен только через параметризацию всех прочих сценариев, в которых эта операция задействована, и никак иначе. Что и требовалось доказать.

Наблюдение 3

Прецедент может быть описан частью сервиса, но лучше для каждого прецедента формировать отдельный сценарий.

Во-первых, наглядность имеет значение. Если каждый прецедент диаграммы прецедентов отображается в отдельный сценарий, то удобнее переходить от диаграмм к коду.

Во-вторых, пластичность имеет значение. Переиспользование специализированного сценария в общем случае проще, чем переиспользование части сервиса.

В-третьих, тестируемость имеет значение. Тестирование сцециализированного сценария в общем случае проще, чем переиспользование части сервиса.

Наблюдение 4

Тестируемость имеет значение, поэтому не следует помещать вызовы всех сценариев в один сервис. Ключевые сервисы, запускающие сценарии, формируют логические домены, которые являются основой модуляризации. Вместе с тем, любая модуляризация приводит к снижению пластичности.