go-micro.dev/v5@v5.12.0/internal/website/docs/architecture/adr-001-plugin-architecture.md (about)

     1  ---
     2  layout: default
     3  ---
     4  
     5  # ADR-001: Plugin Architecture
     6  
     7  ## Status
     8  **Accepted**
     9  
    10  ## Context
    11  
    12  Microservices frameworks need to support multiple infrastructure backends (registries, brokers, transports, stores). Different teams have different preferences and existing infrastructure.
    13  
    14  Hard-coding specific implementations:
    15  - Limits framework adoption
    16  - Forces migration of existing infrastructure
    17  - Prevents innovation and experimentation
    18  
    19  ## Decision
    20  
    21  Go Micro uses a **pluggable architecture** where:
    22  
    23  1. Core interfaces define contracts (Registry, Broker, Transport, Store, etc.)
    24  2. Multiple implementations live in the same repository under interface directories
    25  3. Plugins are imported directly and passed via options
    26  4. Default implementations work without any infrastructure
    27  
    28  ## Structure
    29  
    30  ```
    31  go-micro/
    32  ├── registry/          # Interface definition
    33  │   ├── registry.go
    34  │   ├── mdns.go       # Default implementation
    35  │   ├── consul/       # Plugin
    36  │   ├── etcd/         # Plugin
    37  │   └── nats/         # Plugin
    38  ├── broker/
    39  ├── transport/
    40  └── store/
    41  ```
    42  
    43  ## Consequences
    44  
    45  ### Positive
    46  
    47  - **No version hell**: Plugins versioned with core framework
    48  - **Discovery**: Users browse available plugins in same repo
    49  - **Consistency**: All plugins follow same patterns
    50  - **Testing**: Plugins tested together
    51  - **Zero config**: Default implementations require no setup
    52  
    53  ### Negative
    54  
    55  - **Repo size**: More code in one repository
    56  - **Plugin maintenance**: Core team responsible for plugin quality
    57  - **Breaking changes**: Harder to evolve individual plugins independently
    58  
    59  ### Neutral
    60  
    61  - Plugins can be extracted to separate repos if they grow complex
    62  - Community can contribute plugins via PR
    63  - Plugin-specific issues easier to triage
    64  
    65  ## Alternatives Considered
    66  
    67  ### Separate Plugin Repositories
    68  Used by go-kit and other frameworks. Rejected because:
    69  - Version compatibility becomes user's problem
    70  - Discovery requires documentation
    71  - Testing integration harder
    72  - Splitting community
    73  
    74  ### Single Implementation
    75  Like standard `net/http`. Rejected because:
    76  - Forces infrastructure choices
    77  - Limits adoption
    78  - Can't leverage existing infrastructure
    79  
    80  ### Dynamic Plugin Loading
    81  Using Go plugins or external processes. Rejected because:
    82  - Complexity for users
    83  - Compatibility issues
    84  - Performance overhead
    85  - Debugging difficulty
    86  
    87  ## Related
    88  
    89  - ADR-002: Interface-First Design (planned)
    90  - ADR-005: Registry Plugin Scope (planned)