Skip to main content

The Strangler Fig Pattern

Metaphor​

The pattern is named after the Strangler Fig tree, which seeds in the upper branches of a host tree. It gradually grows roots down to the ground, enveloping the host. Over time, the Strangler Fig becomes strong enough to stand on its own, and the host tree dies and rots away, leaving the Strangler Fig in its place.

Concept in Software Architecture​

In the context of legacy system migration (like WepNG_MVC), the Strangler Fig Pattern is a strategy to incrementally migrate functionality from a legacy monolith to a new, modern architecture (Microservices or Headless) without a high-risk "Big Bang" rewrite.

How it Works​

  1. Identify Segments: Break down the monolithic application into logical, functional domains (e.g., OMGT, BO Anagrafiche).
  2. Interception Layer (The Facade): Implement a routing layer (API Gateway, Reverse Proxy) in front of the legacy system.
    • Initially, this layer routes 100% of traffic to the legacy application.
  3. Implement New Features: Build new functionality as independent services or modules in the new architecture.
    • Update the routing layer to direct traffic for these new features to the new system.
  4. Migrate Existing Features: Pick a specific slice of the legacy system (e.g., a specific controller or service). Refactor/rewrite it in the new architecture.
    • Once tested and ready, switch the routing layer to point to the new implementation.
    • The old code remains in the monolith but is no longer used (dead code).
  5. Repeat: Continue this process until the legacy system is "strangled"—i.e., it handles little to no traffic.
  6. Decommission: Safely retire the legacy system.

Relevance to WepNG_MVC​

For WepNG, this is the preferred evolution strategy over a complete rewrite.

  • Risk Mitigation: We release value incrementally. If a new module fails, we can revert routing to the old one. We avoid the "tunnel effect" of developing for months without feedback.
  • Business Continuity: The system remains live and functional throughout the migration.
  • Target Architectures: Essential for moving towards the intended Headless Architecture.

Practical Steps for WepNG​

  1. Proxy: Use tools like YARP (Yet Another Reverse Proxy) or an API Gateway in front of the IIS application.
  2. Vertical Slicing: Tackle modules like OMGT or BO one endpoint at a time.
  3. Database Strategy: Often the hardest part.
    • Phase 1: New services read/write to the existing database (Legacy DB as shared state).
    • Phase 2: Decouple schemas and migrate data to dedicated stores for the new services (if microservices goal requires it).

References​