Data Transfer Between Loosely Coupled Modules of an Application

Question

Let's say we have a rather large project written in Python using the Django framework that is made up of multiple modules (proper term in Django is a project made up of multiple apps, but for the sake of generality we will use the term "modules"). This is to achieve low-coupling for easy maintainability (among other advantages).

I'm interested in how, during the project runtime, how data would be moved between these modules. As objects? Or as strings?

If data is transferred between modules in the format of an object (as is the case inside the module itself) then low-coupling cannot be achieved. The reason is because one module will be dependent on the object class located in the other module. For example, the module cannot be easily reused in a totally different project because of the dependency on another module.

But if the data is in the format of strings, then low-coupling can be achieved. Separation of duties will be clear, troubleshooting will be limited to a single module, and modules can be easily reused in totally different projects. This is basically how an API sends data to a client.

But is this the proper way of achieving low-coupling - by using strings for data transfer between the modules of a project (read: application)?

Answer 1

This question appears misguided.

You say you want to 'transfer data between loosely coupled modules', but in almost any reasonable real world case, you would be transferring data 'for a reason'. The data (objects) must be understood by the sender, and must be understood by the recipient module. This intrinsically involves coupling of the modules.

(there maybe toy cases you can come up with where it might make sense to transfer data to a module without it understanding the format of the data, but these cases would be rare, and mostly artificial/fake).

Typically, the most natural way to do this in most programming languages would be to have the module that defines the interface (recipient of the calls) also define any objects (or import/reference said objects) that are needed as inputs or outputs for that modules interface.

Yes, this means the caller would need to import (python) the module its calling (but it had to do that to call it anyhow) - and yes, that is a form of coupling. But its one directional, and its really intrinsic to what you are trying to accomplish. There is no useful way around it.

Sure - you could externalize the objects as JSON, or XML, and pass 'strings' or 'raw bytes'. But you would have to format that serialized data just right in the writer (caller) and reader (API being called). That amounts to the same coupling - only not leveraging as well your languages features (classes).