21
Views
5
Comments
Solved
Should my data model definition be in a separate module?
Application Type
Reactive

Hello everyone.

I have been developing a Reactive App...using one single module.

I just learned a bit about architecture, and I think it would be way better for my application to be split into modules. But I have a question...should my database entities be defined in one module, and my UI and another module? If so, how to I even link modules with one another?

As you can see I'm kinda lost as to how to split my app's functionality into modules...any help would be greatly appreciated :)

Rank: #86
Solution

Hi Yizuhi,

Hope you're doing well.

Usually an OutSystems application follows a layer division regarding to its modules:

In your case, if you want to follow a good architecture, you should indeed consider to move your entities and server actions (logic) to a Core Module. The main reason behind this division is to allow several end-user modules to use the same core module (making it reusable). This will also allow your app / modules to be scalable in the future.

Of course there are exceptions to this canvas. For example, if you have a very small app, with just a couple entities and server actions, and you know that it is a very specific app/module and it won't scale or grow up, then there is no impact to have everything in the same module.

But, as I said, this is an exception. The rule is indeed to follow The Architecture Canvas :)


About linking a module to another module, you just need to add the elements that you pretend (for example, entities, actions or structures) as a dependency to your module. The module where you add these elements as dependencies becomes the Consumer module. The module that provides these elements to be used becomes the Producer module.

For that, you should define Producer elements as Public so they become available to be added as dependencies by other modules. As an example:


Back to your Consumer module, if you want to consume those elements from the Producer module, you may add them as a dependency like this:

(Click in the plug icon to open the popup; search for your producer module; tick the elements that you want to add as a dependency to your module)

After this, you will be able to see those elements in your Consumer module :)


Hope that this helps you!


Kind regards,

Rui Barradas

Rank: #2824

Thanks a bunch for your reply, that truly helped me a lot. Now I guess it's time to make some really big changes to my app :')

Rank: #2824

Oh, and one more question: what is a User Provider module? Should one of my modules be a user provider or should I just leave the current Users module (the default option) as the User Provider?

Also, what kind of module should my new Core module be? A service module? A library module? A blank module?

Thanks a bunch in advance.

Rank: #86

Hello again Yizuhi,


About your first question:

The User Provider Module property specifies a source for the user records to be used by this module. For more information, please consider this post where it is given a good explanation about this topic.

Basically, Users application allows you to manage end-users. These end-users can after login in your applications (if you set Users as User Provider). If you access to https://<your-environment>/Users you will be able to manually control these users and their respective roles.

In my opinion, you should leave Users module (default option) as User Provider, otherwise you will lose a lot of the platform's functionalities and capabilities (such as login control, role control and sessions).

More information about this topic here and here.


About your second question:

You may consider to read this article that will help you to understand more about The Architecture Canvas and its layers.

A library module doesn't allow you to consume from other modules (unless they are also library modules or extensions). It is applied for foundation modules (last layer) which is not your case. Read more here.

A service module doesn't allow you to have UI elements. Basically it's a way to enforce you to encapsulate the core service functionality. Read more here.

A blank module is very similar to yours, but without the default screens and functionalities (menu block, login screen, etc.). It is basically an empty module.

That said, you should try to understand which one fits better your needs, because there are always exceptions. For example, you can have a Core module with UI elements (blocks) that are reused in several end-user modules. So you'll need to use a blank module and adapt it (still considering as a Core module).

According to your description, if you just want to have entities and server actions in there, you may consider to use a service module.


Hope that this helps you!


Kind regards,

Rui Barradas

Rank: #2824

Thanks a bunch again, that was really helpful.