Skip to content

Plugin Architecture Pattern Selection

When to Use

Choose the pattern that matches your integration context. Foundation+Extension when mature plugin ecosystems exist. Provider Plugin when abstracting diverse services. Service Collector when building REST API-first integrations.

Decision

Situation Choose Why
Mature plugin ecosystem exists (Commerce, Views) Foundation+Extension Leverage existing infrastructure and admin interfaces
No existing plugin ecosystem for service category Provider Plugin Create standardized abstraction across diverse providers
REST API-first external system integration Service Collector Built-in REST endpoints, webhook support, polling events
Multiple plugin types working together Foundation+Extension Gateway + Method Type + Entity Type coordination
Stateless service aggregation Service Collector Minimal 3-method interface, tagged service discovery
User choice between service providers Provider Plugin Cross-cutting infrastructure (proxy, events, caching)

Pattern

Three Proven Architectural Approaches:

Based on analysis of successful Drupal contrib modules, there are three distinct architectural patterns for plugin systems:

  1. Foundation + Extension Pattern (Commerce Payment Model)
  2. Create foundational plugin ecosystem with multiple plugin types working together
  3. Extensions specialize existing plugin types with service-specific implementations
  4. Leverage existing infrastructure and admin interfaces

  5. Example: Commerce Payment (foundation) → Commerce Stripe (extension)

  6. Provider Plugin Pattern (AI Module Model)

  7. Create new plugin managers for service provider abstraction
  8. Standardize diverse services under consistent interfaces
  9. Build cross-cutting infrastructure (proxy, events, caching)

  10. Example: AI module with multiple provider plugins (OpenAI, Anthropic, etc.)

  11. Service Collector Pattern (Orchestration Module Model)

  12. Aggregate stateless services via tagged service collection
  13. Minimal interface contracts for simple, focused services
  14. REST API-first architecture for external system integration
  15. Example: Orchestration module with webhook and polling event systems

Common Mistakes

  • Wrong: Choosing Foundation+Extension when no ecosystem exists → Right: Use Provider Plugin to create new abstraction
  • Wrong: Building plugin manager for simple REST API services → Right: Use Service Collector with tagged services
  • Wrong: Using Service Collector when plugin alterations needed → Right: Use Provider Plugin for flexibility

See Also