Inherited Architecture Design Question/Issues

I am working on an inherited app which is divided into separate Applications for Core Services, Core Widgets and the Main Application with pages. These pages almost always use several web blocks on each page for the content, even when the web blocks are not used anywhere else. Is this design recommended somewhere? It seems to me that it creates unnecessary complexity. It is sometimes challenging to find where the web blocks lives, and updating a module from Core Services, requires refreshing several core services modules, which then requires refreshing several core widgets, and then refreshing the main module. If I share the OAP from the main application to someone who wants to test the app, I will also need to share the OAPs from the Core Services and Core Widgets right?

mvp_badge
MVP

Hi Joseph,


Modularity is one of the main principles you should observe when developing and in OutSystems is no different. The level on which you split a module depends on various factors.

For instance, you may have teams developing services related to a concept, let's say, customer. And another team developing services related to another concept like product. It would be preferable to avoid having teams working on the same end user module to create the product information or the customer information. In the case, you have core widgets split like that, it would allow to clear define the domain of each team and promote their independence.
Another aspect to take into account is the possibility of those services (in my example the customer and product services) to be used on multiple applications. The widgets split into blocks allow them to be reusable. Not to mention that the end user will be more an orchestrator of those widgets and will not grow as much as if it would have full screens built from scratch.


Answering your final question, if you want to share your solution, indeed you will have to share all the applications which compose the solution.


Kind Regards,
João

mvp_badge
MVP

Hi Joseph,

A modular design is a good thing, but indeed more refresh dependencies actions are required if you change dependent modules. A modular design is the opposite of the so-called monolith where the developer puts all logic in one module and all widgets directly on the screen. A monolith is hard to maintain, loading takes longer, and each 1CP will create a huge module version to be created.

I don't get your last sentence "If I share the OAP from the main application to someone who wants to test the app, I will also need to share the OAPs from the Core Services and Core Widgets right?"

Why would you need to share modules, for testing? To test an application you share the application url.

Regards,

Daniel

I totally understand creating separate modules. However, this went a step further and separated the core services modules into a separate application, and the same with the core widgets, and the end user screens. Three applications to create one application that all have to be promoted to the next environment. An application is supposed to be the smallest unit that should be published. None of these 3 "applications" can be promoted alone. I would have grouped all the modules into one Application.

The idea of having more modules to allow more developers to work at the same time also hasn't worked well here. You work on a web block in a core widget module, and if you change server actions, etc., you also need to work on the related core services module. And since each page in the end user app is filled with web blocks, it is highly likely that two developers will be making changes on the same core widgets module, and the same core services module, and the same (and only) end user module. When you push your changes, you publish the core services module first, which makes other core services modules need refreshing, which makes other core widgets modules need refreshing, which makes the end user modules need refreshing. 

Outsystems does an amazing job of merge publishing, thankfully, and notices the other user changing separate web blocks and separate server actions, and keeps everything in sync. Still, it just seems that you should only use web blocks if they are meant to be reused, since they add complexity to what would otherwise be a simple page.   

mvp_badge
MVP

Of course, it depends on the use case, there's no recipe answer or the best architecture. The architecture should be the best that supports the use case and the needs, which are different from project to project.

You mentioned, and rightfully so, that applications are the smallest unit to deploy but they are also the granularity level on which you give access to. For security segregation purposes, people working in application A might not be able to even access Application B and you can only do that at an application level. Applications may also have different owners and so on.

Regarding the merging, I think it works well, indeed, but in any case, you should avoid having more than 1 team working in the same area, on the same code and merging can take time and be more troublesome, specially if you have a lot of people working on the same things in the same module.


All in all, each solution is different and it might make sense in your case to have just one application. My answer and Daniel's, not knowing the particularities of the application, focused on the advantages of partitioning the solution in multiple applications in general. Once again, it depends on the use case and on the situations previously discussed here.

To finalize, there are a few courses and documentations that guide on the "rules" for correct application composition, I advise this one.

Someone wanted to test installing the app on a completely different Outsystems server in another division. Not simply testing the functionality of the app.

Thanks for the discussion. Have you ever seen an architecture where all web blocks were in one application (multiple modules based on the concepts), all services were in a separate application (multiple modules based on same concepts of the modules in the core widgets application), and all pages were in a third application? The original developers are long gone and I am trying to figure out if some expert advised this application, and if so, why? I've been through the courses, and this approach just doesn't seem to fit the advice in the courses, to me.

mvp_badge
MVP

Yes, it doesn't sound exceptional to me.

mvp_badge
MVP

If your company needs  a technical architectural assessment of this application, the company I work for can deliver that expert service.

Thanks, Daniel. I wasn't involved in the original architecture, but I am architecting a new version going forward. Your comments, as always, are thorough and thought provoking.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.