Data exchange between end user and core business layer

Hi, 

I have a question regarding data exchange between end user and business layer (business module is inside the core layer). My requirement is to develop web as well as mobile version of the application, therefore I plan to provide a reusable business layer to support both type of applications. The server actions are to be created in business logic layer that accepts as well as return entity related information, in order to support that I have two options:

1. Exchange information using structures - Using this approach I can ensure that end user layer is just referencing the business layer and not the core module or its entities. This approach also makes more sense because the server actions are not able to optimize the aggregate performance when server action output is output of the aggregate, and definitely there would be scenarios when screens don't need all the fields contained in an entity.

2. Exchange information using entity records - With this approach one problem I see is output of aggregates in server actions not being optimized, and if I have to return the specific fields then I would have to use the structures which take me back to option 1. However, this approach saves me creation and maintenance of structures in the application.

Please share your inputs and let me know what OutSystems best practices suggest in this scenario.

Hi Junaid,

This is something that comes up a few times for anyone designing their layers. It's always going to depend on the specifics of what you're building, but I can tell you that at least for me, it comes down to a hybrid between your two options. 

Using structures for everything in order to not reference the core layer is a valid option, but in practice, if you're managing dozens or hundreds of structures, you'll find the effort outweights the rewards. There's something that you mention in your post, in that the moment you encapsulate an Aggregate in a server action, you have already lost the field optimization - the platform only optimizes them when you use them directly. It's always going to depend on exactly what you're doing, but the decision ends up being maintenance versus isolation. You can certainly detach the core from the frontend completely, but this is going to balloon your efforts in maintaining your code.

If your main concern is Aggregate optimization, your best bet would be to identify the Screens and Aggregates that don't require a lot of logic, and instead of encapsulating them, use them directly on the frontend - which means that you end up referencing the Core modules.

The best practice is to carefully evaluate if you really need to encapsulate your data fetching, and this is going to depend on how well you know your project: if you have an Aggregate with 20 filters being used in only one place, it's probably good enough to leave it as it is. But what if you need to reuse it elsewhere? Now you have 20 filters in two different places to manage. Should you encapsulate it now and lose the optimization to be prepared for the future? That sort of thing is going to come down to knowing how your project is going to evolve.