Art of Software Reuse
  • About
  • Introduction
  • Why Do Reuse Efforts Fail?
    • Common Pitfalls
    • Conway's Law
    • Care About Risks
    • Pursuing Perfection
    • Lack of Domain Focus
    • Entropy
  • Tenets
  • Success Factors
    • Revisit Assumptions
    • Communicate, Constantly
    • Collaborate
    • Review Code
    • Be Domain Driven
    • Target Quick Wins
    • Reduce Friction
    • Document
    • Build for Immediate Use
    • Address Support Needs
    • Managing Complexity
  • Practices
    • Minimise Jargon
    • Leverage Interception Points
    • Delay Commitment
    • Never Waste A Production Incident
    • Be Disciplined
    • Be Demand Driven
    • Continuous Alignment
    • Iterate, Iterate, Iterate
    • Build a Product Line
    • Understand Lack of Reuse
  • Design
    • Wrap Legacy APIs
    • Think Products, Not Applications
    • Identify Common Needs
    • Create Common Connectivity Components
    • Consistent APIs
    • Manage Domain Variations
    • Evolve Functionality Iteratively
    • Offer Reusable Assets with Multiple Interfaces
    • Leverage Services Across Functional Flows
    • Mediate Service Requests & Responses
    • Refactoring
    • Abstract Utility Functions
    • Reduce Technical Debt
    • Facilitate Extensibility
    • Encapsulate Variations Using Patterns
    • Understand Adoption Barriers
    • Ease Testability
    • Supportability
  • Tips
  • Resources
Powered by GitBook
On this page

Was this helpful?

  1. Design

Wrap Legacy APIs

PreviousDesignNextThink Products, Not Applications

Last updated 5 years ago

Was this helpful?

Your enterprise probably has legacy software assets that are extremely valuable and can be the basis for your initial project deliverable. If you don’t take care and start reusing straight away you will end up with lots of point to point connections…

Now, all the consumers are directly consuming your legacy asset with all the ill effects of tight coupling. You want to change or upgrade the legacy asset? it might break every consumer and force them to make changes to their code. Plus, you will expose your legacy error codes, naming conventions, behaviors to all your consumers.

Bad idea. So what do you do?Don’t reuse legacy software assets as-is;wrap them first!

Create a component that wraps the legacy asset – it now sits in be the legacy asset and the consuming code (which could be your app, an external process, a batch job, whatever…). This wrapper component needs to provide a contract that is in alignintment your enterprise’s data standards, should reuse your enteprise’s data types, use standard error codes, and most importantly should not expose legacy naming and/or implementation semantics.

wrap_legacy_asset_reuse

Why this is important? Well, if you don’t have a wrapper that truly encapsulates the legacy functionality it will serve only as a pass-through layer adding no value. The wrapped asset now can be reused by multiple consumers and you have the flexibility to change the implementation. If you keep your interface constant, your consumers won’t need a code change and only need to regression test.

legacy_asset_reuse