I am building a new system, which I will call S, that needs to get some data from another system, which I'll name D. System D provides a client and a collection of classes(POJOs) to represent the responses in memory. Instead of using the client directly everywhere, I am writing a sort of adapter which will handle all the interactions with the dependency.

Now, to stay true to my initial goal of letting the adapter handle all the interactions, I don't think it is good idea to let the adapter class return data using the POJOs provided by system D because the rest of my system(S) would, in some way, know a lot about system D, which is what I want to avoid in the first place. My concern is that to achieve this ideal, I would have to write the equivalent(not identical, only the data I need) POJOs in my system when system D already provides those for free.

Do you know of a design principle that could help me decide(support my idea) in this situation?

If you have faced this situation before, how have you approached it?

UPDATE: Thanks for your comments, they helped. I went for the less coupling, more POJOs approach and I think it was a good idea in my situation because later I realized that we need to combine a few POJOs provided by system D to make things more convenient for the new system, so it's not exactly a 1-1 relation.

  • 5
    You'll have to decide which is more important to you: better decoupling or fewer POJO's. May 8, 2019 at 20:24
  • That's what I am afraid of :(
    – rendon
    May 8, 2019 at 20:48
  • 1
    This is classic dependency inversion - you introduce an abstraction. Just think about these data structures as being a part of that abstraction - the interface (in the general sense of the word) between the two systems. The problem is that you have to carefully design them (perhaps, over time) so that they support your needs, but still let you evolve the two systems independently to a significant degree. May 8, 2019 at 23:25
  • 1
    Indeed it's a decision between "better decoupling or fewer POJOs". However, calling it an "adapter" sounds like you subconsciously already made the decision (and are maybe just struggling with the idea of having "duplicate" code). Wikipedia: "An adapter or adaptor is a device that converts attributes of one device or system to those of an otherwise incompatible device or system.". At least semantically, if S uses the D POJOs, it's not incompatible with them. It would just be "the code using D" instead of "a D adapter". IMHO.
    – R. Schmitz
    May 9, 2019 at 9:46
  • @R.Schmitz I think you are right, I made the decision when I decided not to use the client directly.
    – rendon
    May 9, 2019 at 18:19

3 Answers 3


a design principle that could help me decide(support my idea) in this situation?

System S shouldn't know System D exists. Pretend system D didn't exist. Now write data structures (POJO's, collections, whatever) that do what system S needs in the most convenient way possible. Now your adapters job is simply to convert the data from one systems form to the others.

It can be tempting to make the structures identical. Then the adapter is at most a brainless shunt. And now you're stuck with structures full of crap you don't need organized in a way that doesn't help. Wouldn't it have been nicer if that was taken care of before you had to think about solving the hard problems?

  • 1
    The problems with this really appear when system D changes it's API or you need to integrate to systems E, F, and G as well as D. It's no fun trying going through the code figuring out parts of the structures are actually used.
    – JimmyJames
    May 9, 2019 at 21:19
  • 1
    @JimmyJames a formal API is a wonderful way to make your needs clear. But it should only include your real needs. Not things you think might be nice some day. May 9, 2019 at 23:06
  • I might be misunderstanding you're comment but i wasn't suggesting a formal API. What I would recommend is that when you are integrating to the first system (or version), you build a facade that exposes/uses only the functionality you need. It's quick and easy and makes things cleaner. Later when that system is upgraded and/or needs to be replaced and/or you add more systems, you've got a clear blueprint of what your dependencies are.
    – JimmyJames
    May 10, 2019 at 14:55

If you want the best decoupling you must write your own POJOs, yes is more coding but is the way to go. If you're alright with the level of coupling and dependency of system D you can use his POJOs. But if you write adapters for limiting the coupling between the two system your must continue with your decision and write your own POJOs

  • 1
    I would add that the additional layer can be very helpful in an architecture, as it offers a natural place to customize any mapping between third party business attributes and your own-- this is often a critical part of the application, so it's nice to give it its own, dedicated portion of code.
    – John Wu
    May 9, 2019 at 18:40

If you can compile the sources of the dependant system "d" yourself or if you can replace factory methods for "d"-dtos you can create java-interfaces for the used part of the d-dtos and use these in s instead of the original. This way s sources will only depend on your own interfaces instead of d-dtos

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.