Я думаю, что вы путаете единственную ответственность с разделением интерфейса.
С точки зрения интерфейса клиент / сервис, вы должны держать свои контракты скудными и подлыми. Ниже приведен пример этого.
На стороне SRP это должно быть полностью внутренним для реализации сервиса, и клиент не должен знать об этом. Если ваш сервисный код слишком велик, разбейте его на классы. Затем сделайте ваш сервисный код, по крайней мере, на начальном этапе, действующим как фасад и перенаправьте все вызовы соответствующим объектам. Позже у вас есть возможность разделить ваш сервис на несколько сервисов. Но имейте в виду, что SOA и объектно-ориентированный дизайн, хотя и частично совпадают, имеют разные требования.
Пример разделения интерфейса: у нас здесь есть служба, которую мы используем для выполнения различных функций в некоторых бизнес-объектах. Оригинальный сервис имел один интерфейс. По мере роста мы поняли, что у нас есть три семейства методов: сохранение объектов данных, бизнес-обновления, бизнес-анализ. Мы разделились на три контракта. Наш клиент / сервис реализует все 3, поэтому единственное, что нам нужно было сделать, это разделить контракт на три и настроить две дополнительные конечные точки в нашей конфигурации WCF. Очень просто.
Надеюсь, это поможет.