Здравствуйте, Аноним, Вы писали:

А>Я уже несколько дней голову ломаю никак не получается придумать вариант реализации бизнес-логики.
А>Итак, есть BL, состоит из ~20 пунктов, каждый пункт состоит из ещё ~10 подпунктов.
А>Отмечу, что данная BL описывает use case регистрацию нашего приложения с мобильного устройства к нашему сервису.

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

Если так, то это типичный кейс применения паттерна "сага". Сага — это машина состояний, конечный автомат (скорее даже так: в методологии SOA для паттерна "конечный автомат" зачем-то придумали отдельное название "сага" ). У саги есть внутреннее состояние (обычно хранится в персистентном хранилище, но необязательно) и есть обработчики входящих событий, которые это состояние могут менять. В Вашем случае события — это вызовы методов сервиса девайсом.

Логика переходов саги между состояниями очень удобно описывается диаграммой состояний. Логика обработчиков событий — (например) диаграммой последовательности. Типичный алгоритм обработки очередного вызова от девайса может выглядеть так:

    Если КусокДанныхN еще не сохранен, то:
        Провалидировать КусокДанныхN
        Если КусокДанныхN невалиден, то:
            Кинуть исключение (девайс получит ошибку)
        Сохранить КусокДанныхN
        Перевести сагу в состояние _КусокДанныхNСохранен_

И вот хорошая реализация этого паттерна для .Net.

Нечто подобное можно написать и с помощью WWF, только работать будет медленно.
Есть, наверно, и другие реализации.
Можно и свой велосипед натворить.