Я думаю, что ваши сложные проблемы с дизайном находятся на другом уровне, чем адрес шаблонов проектирования.
Конечно, вы можете применять Фасады перед своей основной бизнес-логикой, открывая различные интерфейсы
MyServiceV1 { // the original interface
MyServiceV2 { // the new interface
и так далее.Я вижу интересные моменты проектирования, связанные с тем, как вы реализуете старый интерфейс с новой реализацией.Например, предположим, что в старом интерфейсе у вас есть метод, создающий некоторый бизнес-элемент
createItem( String name,
Integer value);
, а в новой версии у вас есть
createItem( String name,
Integer value,
String justification
);
Так что, когда на фасад приходит запрос v1, онне будет данных для «обоснования», так что должен делать фасад?Возможно, добавьте некоторую «НЕИЗВЕСТНУЮ» ценность, но то, что вы делаете, - это не столько вопрос дизайна, сколько понимание требований бизнеса.Очевидно, что есть много хитрых проблем такого рода, в зависимости от различных изменений, внесенных при создании новой версии служб.
Итак, сначала работаем через интерфейс через интерфейс, понимая требования, политики для работы сразные изменения.Это приведет к различным проблемам с реализацией, и когда вы доберетесь до них, вы можете начать видеть шаблоны в реализации, которые заставят вас принять явные шаблоны проектирования.