Skip to main content

Solution Strategy

The Solution Strategy describes the fundamental architectural decisions and the "how" behind the framework's design.

4.1 Hexagonal Architecture (Ports & Adapters)​

Framework M uses Hexagonal Architecture to maintain clean separation between business logic and infrastructure.

┌─────────────────────────────────────────────────────────────┐
│                    Primary Adapters                         │
│              (HTTP, CLI, Background Jobs)                   │
└─────────────────────────────┬───────────────────────────────┘
                              │
                    ┌─────────▼──────────┐
                    │    Core Domain     │
                    │  (DocTypes, Logic) │
                    └─────────┬──────────┘
                              │
┌─────────────────────────────▼───────────────────────────────┐
│                   Secondary Adapters                        │
│        (Database, Cache, Storage, Events, etc.)             │
└─────────────────────────────────────────────────────────────┘

4.2 Protocol-Based Design​

Framework M defines Protocols (interfaces) for all infrastructure concerns.

This decision allows for:

  1. Swappable Infrastructure: Swap implementations (e.g., PostgreSQL for SQLite or Kafka for NATS) without changing business logic.
  2. Testability: Test the core in isolation using mock adapters.
  3. Deployment Flexibility: Deploy with different infrastructure stacks (e.g., Redis for caching in production, in-memory for local dev).

See Protocol Reference for individual interface contracts.

4.3 Macroservices and Service Orientation​

Framework M advocates for domain-scoped services that can be extracted from the monolith as Macroservices when independent scaling is required. This avoids the overhead of microservices while providing a path for future decomposition.