If you have a big legacy application (big ball of mud), lets call it MudApp.

If you then create a new application to make us of new technology and to make a new good looking frontend because that was impossible in the MudApp. This new application is supposed to the fresh one and with only the most important features of the MudApp. Lets call it MobileApp.

Some features is really difficult to implement in the MobileApp with identical functionality as in the MudApp so the solution has been to just make a request (via API, SOAP or whatever) from MobileApp to MudApp and let the MudApp do all the work. Some other features is written directly inside the MobileApp.

My first thought is that this is bad with to much coupling between them etc. But I can not really make an argument for why it's bad.

So my question is:

Is this bad or good? And why?

Note 1: the applications is sharing database (which for some is bad practice, but in this case I think it's fine because it would be to much work syncing to another database and so on.)

Note 2: The reason for the question is because the MobileApp is supposed to be further developed. Some features will be added and some removed. So I'm trying to figure out if the NEW MobileApp should make us of the current MobileApp (Took approx. 2-4 month to write) or just start over on a clean sheet

  • Does this answer your question? What is an Anti-Corruption layer, and how is it used?
    – gnat
    Mar 1, 2021 at 6:38
  • 2
    You are approaching this from the wrong angle. The main question to ask evaluating this as "good" or "bad" is, is it economic - especially more economic than the alternatives.
    – Doc Brown
    Mar 1, 2021 at 6:52
  • @gnat Hmm. I'm not sure. I guess the SOAP part acts like a kind of ACL. Would you prefer a ACL to the old codebase or that the new code talks directly to the database itself?
    – emajl
    Mar 1, 2021 at 7:04
  • @DocBrown That is what I'm trying to do. In short terms it will of course be most economic to use the old codebase via SOAP. But I'm trying to find out if it is the best in the long term too. I dont want myself painted into a corner.
    – emajl
    Mar 1, 2021 at 7:08
  • This depends on so many things. Is the old code base just hard to extend, or is it behaving flakily? How much does your developer time cost compared to the cost of the next time-to-market? How much further development is expected on the new code base? Mar 1, 2021 at 7:36

2 Answers 2


Surface Area

The problem is that any change now requires consulting two or more "separate" code bases using different styles, conventions, frameworks, and perhaps even languages, paradigms, or platforms.

The surface area that must be explored is larger, and necessarily includes the dark, and dank area inhabited by the decaying mud ball™.

Worse some changes require work in both the old and new world. This is seriously limiting. Either you must:

  • envision two distinct solutions, and a clean mapping between them.
  • or implement a single common solution which suffers the worst constraints of both the new and old world with none of their unique benefits.

In neither case are you being setup for success. Just more misery...

Clean mappings are Hard as anyone who has had to massage data from one database to another well knows. Which is made worse by the fact that the best solutions in the new and old world will probably have incompatible data models.

The single common solution means that not only are you writing bad code, you are writing code fundamentally worse than what was present in the old world. To top it off, if you ever sever the link to the old world, you are already stuck with this tragic implementation. If by a miracle the implementation is actually mildly okay or actually good code then you have a maverick genius and the fates have smiled upon you - just don't rely on it to be true for the next Code Change™.


This is why the Coupling is so bad. Its not that you have a shared database, or shared APIs. Its that you have two different paradigms of implementation duking it out without a good boundary between the two keeping the peace.

If you do happen to have a decent boundary between the two, its hard to maintain. Largely because the two code bases co-habitat quite closely: sharing common data, data-structures, and are attempting to solve the same problem.

You can envisage them as two large stars slowly eating each other as their close proximity allows their gravity to ripe at the other one.

Anti-Corruption Layer

An anti corruption layer is a good start. Its like a microservice (even if its just a dll) that stands as a guardian of the integrity of shared data structures. Usually it protects a database, but you could have similar guardians responsible for shared communication streams. Their goal is to ensure that neither program puts the data-structures into a bad state due to bad code, asynchronous behaviours, or luck.

Tight Modules

Start enforcing module boundaries. It might be ugly on the inside, but a tight module is also a replaceable module. No code from the new or old world is to directly access the implementation (aside from the "entry" class).

Module Level Tests

Also advantageously, a tight module is much easier to test, and tests improve the quality of life for you when dealing with legacy code, even if its written in the new world.

  • The connection between the codebases is like this: MobileApp Controller -> MobileApp Service -> MobileApp setup SOAP connection and preparing parameters to be sent -> SOAP request to MudApp -> MudApp receiving request -> MudApp doing the business logic. To clearify: you are saying that this is bad and that it should be using ACL and Tight Modules?
    – emajl
    Mar 2, 2021 at 10:27
  • 1
    I'm saying the more code bases you have to investigate for one change, the harder it is to assess, the more difficult it is to solve, especially when they share common data stores/communication channels. Its not that its bad, some surface area can be a good thing, too much across languages, paradigms, styles, etc... can be a very bad thing. Its like getting to foreign countries to agree on something - difficult at best. The feeling of unease you have is that you can sense this state of affairs approaching, and you want to avoid it.
    – Kain0_0
    Mar 2, 2021 at 22:21

Prepare to become yet another team who realizes the very-hard way that "it cannot be done." You cannot "screen scrape" from the existing app. You must create new interfaces within it – interfaces which the legacy language never contemplated and therefore does not at all support. The reality is that you are facing re-implementation.

I've spent a couple decades now, teaching this lesson to one company after another after another.

  • I don't understand. What do you mean with screen scrape? The connection between the codebases is like this: MobileApp Controller -> MobileApp Service -> MobileApp setup SOAP connection and preparing parameters to be sent -> SOAP request to MudApp -> MudApp receiving request -> MudApp doing the business logic.
    – emajl
    Mar 2, 2021 at 10:30
  • Yes, truth of the matter is that the mud ball needs rework for each new feature.
    – Kain0_0
    Mar 2, 2021 at 22:27

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.