Есть несколько вариантов.
Концептуально, самое простое - создать 3 разных приложения, используя их по возможности. Таким образом, у вас может быть «движок», обеспечивающий общую функциональность, и 3 отдельных приложения, работающих на движке - «базовый», «расширенный», «полный». Это своего рода разновидность операционной системы MS - движок является базовой операционной системой, а разные версии содержат различные приложения, созданные поверх движка.
Преимущество этого пути заключается в том, что вы можете создать концептуально действительный продукт - у вас нет большого количества зависимостей между выпусками, и если «полная» редакция решает не включать функции из «базовой» редакции, потому что они не не имеет смысла, им не нужно беспокоиться о нарушении этой зависимости.
Вторая модель заключается в создании отдельного приложения и управлении его поведением посредством конфигурации - либо во время сборки, либо во время выполнения. «ifdef», например, позволяет одному файлу кода C ориентироваться на разные операционные системы; количество процессоров, поддерживаемых разными версиями одного и того же ядра базы данных SQL, может контролироваться конфигурацией во время выполнения.
Это имеет то преимущество, что у вас есть единая база кода для управления, но обеспечивает очень тесную связь между редакциями и быстро становится неуправляемым.
Многие приложения используют модель «plug-in»; это вариант первого варианта, так как он требует от вас сначала создания приложения платформы, а возможности каждого выпуска ограничены возможностями вашей платформы. Многие игровые программы спроектированы таким образом, и разница между версиями в основном зависит от того, какие плагины поставляются с игрой.
Это очень чисто архитектурно, но представляет реальный риск для проекта - все ваши самые умные разработчики захотят работать над фреймворком, а никто не хочет работать над реальным продуктом; если ваши разработчики фреймворков неправильно догадаются о реальных требованиях, вы получите блестящую фреймворк, который поддерживает не тот продукт. Кроме того, фреймворк имеет тенденцию фокусироваться в основном на компьютерных проблемах, таких как ведение журнала или конфигурирование плагинов, а не на реальных бизнес-вопросах. Я видел это из первых рук, и это было довольно трагично.
Если у вас нет неограниченного времени и бюджета, я начну с варианта 1 и перейду к варианту 3, как только вы выпустите свой первый релиз.