Core vs global module

Support
#1

Hi,

I have been developing with Cuba for a while now and the project is growing to a point where the overall structure is becoming a bit messy.

While I have learned a lot about the framework, I still cant decide what should go into the global or core module. My question is what are the big differences between the core and global module, what are considered to be good practices and how to generally go about this when creating services/components.

Right now, I have pretty much placed all my business logic into single @Component’s (no interfaces) in the global module. That includes components that do pure computations, work with the DB, handling 3rd party integrations etc. What I have in the core module are entity listeners and some scheduled tasks. I’d say the code is split roughly 5-95% between the core and global module, respectively, excluding the web module.

If anyone could shed some light on this It would be greatly appreciated.

#2

Hello @bartekspitza,

I divide this up like this :

Web Module: Components and configurations and logic that only refer to the UI. Also external libraries, which are only used for the UI, I put in here.

Global module: Contains the entities and the service interfaces and configurations that are needed in the web and in the core. No business logic.

Core module: Contains the actual business logic. Classes I call in the web module are packed into services, everything else is packed into beans.

When designing an application I orientate myself on the “Boundary Control Entitiy” pattern, which is well described by Adam Bien here.

Boundary = Services in CUBA, where the interface is packed into the global module and the implementation into the core.

Control = Beans in CUBA; they are only used within the core

Entity = Entities in the global module in CUBA

I hope I could help you.

Greetings
Andreas

3 Likes
#3

What are the advantages to dividing your services like this contrary to defining and implementing a service directly in global?

#4

The first advantage is a clean separation between business logic and UI. The division into services and beans defines exactly which classes are accessible from outside (UI) (boundary) and which are not (beans).

Another advantage is that you can scale the application as the number of users increases. You can find more information here.

Greetings
Andreas

#5

The first advantage is a clean separation between business logic and UI

Couldn’t this be achieved by just using the web and global module?

The division into services and beans defines exactly which classes are accessible from outside (UI) (boundary) and which are not (beans).

This could be achieved with access modifiers (public/private) on methods, no?

#6

Hi,
First, it is OK to put all logic to the global module if you don’t encounter any problems.

However CUBA advices to put business logic to the core module.
I can name the following practical reasons:

  1. In the CUBA application there are two spring application contexts: one in core module and another is in web module.
    Beans declared in the global modules are instantiated twice: first time as part of the core module, second time as part of the web module.

So if you declare some state in the bean, you could sometimes notice some glitches.

  1. Beans declared in core module can use additional persistence APIs: native queries, mybatis, EntityManager, long transactions etc.
    Beans declared in global module can only use DataManager.
    Implementation of the DataManager in the web module uses DataService - middleware service - under the hood.

  2. Between web and core modules there is a transparent boundary: when middleware service is called, all parameters and return values are serialized and de-serialized under the hood.
    Thus if you are using a lot of bulk data loading in your beans, you should expect a little bit higher CPU usage and memory allocation if your beans are located in global module (and called directly from screens - so that web-level bean is called).

3 Likes