Quali sono alcune idee di progettazione per un'applicazione di mappatura e trasformazione dei dati?

Ecco uno schema di alto livello del progetto:

• Abbiamo spesso bisogno di convertire i dati da un nuovo sistema in entrata al nostro sistema interno (una sorta di processo ETL di base)
• Preferiremmo farlo dinamicamente, consentendo ad un analista di utilizzare una GUI per mappare i campi di origine ai campi di destinazione e definire le trasformazioni di base
• Il flusso di base sarà il seguente:
  1. Il client fornisce file flat con dati di origine
  2. Il programma scarica questi file flat in un database SQL Server (senza trasformazioni)
  3. L'utente mappa i dati e definisce le trasformazioni in una GUI basata sul Web
  4. GUI chiama i servizi Web che eseguono le trasformazioni e generano nuovi file nel formato di sistema di destinazione

La mia responsabilità saranno principalmente i servizi menzionati al punto # 4.

La mia domanda è: qualcuno ha qualche suggerimento sulle migliori pratiche per progettare un'applicazione come questa? Il mio primo pensiero era quello di fare in modo che i servizi accettassero oggetti che rappresentano un oggetto business (ad esempio un account) e tutti i campi e le informazioni di mappatura / trasformazione per quei campi.

Esempio veramente approssimativo:

//BusinessObject --> Field

//Example: Account

{
    fields:[

    {
        targetFields: ["NUMBER"],
        sourceFields: ["AccountNum"],
        transformations:
        [
            {
                type:"trimspaces",
                expression:""
            },

            {
                type: "format",
                expression: "%03d"
            }
        ] 
    },

    {
        targetFields: ["NAME"] //etc...
    }

    ]

}

In questo esempio, un campo obiettivo appartenente all'oggetto Account denominato "NUMBER" verrà popolato con il campo sorgente "AccountNum" con due trasformazioni applicate (spazi di assetto e pad con 3 zeri iniziali).

L'utente avrebbe un numero finito di opzioni di trasformazione tra cui scegliere, quindi questo renderebbe la codifica back-end un po 'più semplice.

Sto anche pensando che le trasformazioni avrebbero ciascuna le loro sottoclassi di una super-classe di trasformazione in modo da evitare di dover fare una logica speciale per ognuna. Ogni sottoclasse implementerebbe solo un'interfaccia comune. Ho usato solo l'attributo "type" qui, ad esempio.

Questo approccio ha senso per il lato API? O sono completamente fuori con questo?

Qualche suggerimento sarebbe apprezzato!