DEV Community

Discussion on: Have you built a modular monolith?

bertilmuth profile image
Bertil Muth Author

If that worked for you, great. I wonder if there were certain rules in your codebases. For example: could the UI access business logic, and the business logic the UI as well? Probably not (I hope). Maybe there were clusters of objects, and you accessed only one of them and so on. Modules make these structures explicit - sometimes simply using packages or similar language constructs. A module is a cluster of objects with a well defined interface.

Thread Thread
efpage profile image
Eckehard • Edited on

I cant remember that we had any trouble organizing the data flows. Usually you want to keep your interfaces narrow and the class free of any dependencies. So you use callback functions to connect your UI to the business logic.

Think of a calculation tool with numerous inputs elements. You build a class that creates all or some of your input elements. The class has only three callbacks:

  • onInput
  • onUndo
  • onDismiss

When you use the class, you CAN apply these callbacks, but you don´t need to.

If the user inputs some data, the class collects all the data from the UI. If a callback is installed, it sends a JSON object with all the data. Or, it just sends a message that new data have arrived and lets the external logic grab the data they need directly. But in any case you do not need to know, WHO installed the callback.

So, you can establish direct connections between the business logic and an UI this way, but often you will use some kind of dispatcher to organize the data flow more explicit. So, the dispatcher installs the callback and gets informed, when a user input happend. Now he can decide, how to handle the message.

I know that there are lot´s of applications, where each button has it´s own event function. That brings you this kind of spaghetti data flow we should avoid. But if you start developing your UI based on classes, this is a way to organize the dataflow too.