I have the following situation in my current project:

There is a system A which exports data, that will be consumed by system B. System A is something like a webshop which exports data like orders to an ERP (system B).

Unfortunately, system B dictates the export format to work proper. The typical awkward stuff like "you have to set this field to that and this other field to that otherwise my System B will not work". Data that is something really deep from the ERP's side ... stuff like flags, that just has the ERP to know in my opinion.

I would say, that is a typical case where you should invert the dependency between these two systems to have no implicit knowledge for external systems. So that means System A should provide the export as it is from the view of the webshop, independent from other systems required format. Every system that is interested in the data of A can transform that data to the format that is needed on their side ...

The argument here is to resolve the dependency. You don't have to be worry when you change something regarding the export on System A, because you cannot ran into trouble with values that are out of range in System B for example.

But the counterargument from the opposite site is:
Ok, now you are independent from the system B's side but now the system b is dependent of what you as a system A provide. So you just moved the dependency, but you have won nothing. Because all the effort is now on system B and if you change something on system a, nothing works on system b anyway ...

Honestly, I can't really find a valid argument against that statement.

Are my thoughts generally right anyway? At least it feels much cleaner this way but would make no sense to put in effort here if its changes nothing real in the end.

What is the clean approach here and what are the arguments?

Any other suggestions here?


1 Answer 1


I try to avoid the term "clean" here, since I think it is pretty overtaxed.

A standard approach is to introduce a "middleman" component C which does the transformation from the exported data format from A to the expected data format of B. C will then depend on A and B, of course, but neither will A directly depend on B, nor vice versa.

Of course, if this is the most suitable solution depends also on who will be reponsible for the maintenance/evolvement of the systems/components A, B and C. If A and C are evolved by the same team/organization, making C a part of A may be more suitable. Same if B and C will be evolved by the same organization, then making C a part of B makes probably more sense. But if A, B and C shall be evolved by three different teams or organizations, then keeping this as three different components will be most sensible.

  • But with the approach "dependency inversion" (if this is the right term here) you cannot reach a more flexible solution, right? The Problem is, that it's not really clear which system will have more to do with the transformation. Today it seems that this is system B but later on it could be that multiple systems are interested in the data of A, so its more on the A's side then. But clear to me is that a web shop should really not have any detailed knowledge of data in B. The dependency now goes so far, that the export of the web shop controls stuff on the invoice print.I hope everybody agrees.
    – Jim Panse
    Commented Aug 18, 2020 at 8:33
  • Anyway, is there a name for that kind of middleman pattern?
    – Jim Panse
    Commented Aug 18, 2020 at 8:39
  • @JimPanse: call it the Fundamental theorem of software engineering, if you need a name for it.
    – Doc Brown
    Commented Aug 18, 2020 at 9:09
  • Yeah i heard of it :D Everything is solvable by that ...
    – Jim Panse
    Commented Aug 18, 2020 at 9:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.