I am fairly new to Outsystems. As a sole operator, I watched all the videos and did all the learning. I have a good grasp on the architectural concepts and the 4LC. I am building an application (still my first). I started with the database in one module and all else in another. I figured I would break the "all else" up into a proper architecture once I understood better how things would come together. Well 110 screens and 120 server actions later it is time to add completely different UI functionality. So, I have to tackle the architecture before I create the new UI.

Current Architecture


This is when I discovered that a simple assumption was wrong. I assumed I would have one application with multiple modules. Now I see that I could have a solution with multiple applications. I am not able to confidently understand the pros and cons of these two approaches. Can someone help?

Target Conceptual Architecture

Both UIs (PfM and PgM) will consume all server actions and the database. Server actions in all three groups (whether module or application) will need to consume the database. This is a multi-tenant application.

Is there a compelling reason to build these as applications in a solution as opposed to modules in an application?

  •  Is one significantly more appropriate architecturally?
  •  Is one simpler to break apart and then maintain?
  •  In either approach can I simply cut and paste existing server actions or is it more complicated?
  •  Do the server actions belong in a blank module or a service module

Thanks for your assistance.

The reason to separate your concepts and their composition into different applications isn't easy to answer if you're just looking at your current application. This brings you more granularity, and right now the only advantage you can decisively identify is that it's easier to work with if you have a larger team, since code is more spread out between more modules.

But let's move past and say that you do finish your application split apart into modules and not as applications. It works fine, great! But now you need to build a second application, and it will reuse logic from the first one. You're now adding dependencies between two separate applications - every time you need changes in your first application to service your next application, you'll need to group this code and move it together - painful if you ever have to manage multiple applications being simultaneously developed. The base unit for Lifetime deployments are applications, so every time you need to move one tiny change, you'll be moving everything in that base unit.

Now assume that you did split your work into multiple applications. Imagine you need to build a second application on top of the logic of your first app. This is going to need changes in your Health application. Since the concept of Health for you is isolated in an application, other applications that use it are isolated, and won't be "dragged" alongside any deployments you need to do of changes to Health.

Great explanation, Afonso, and a great case for future growth. I intend to grow. 

Is there a downside to maintaining multiple applications while still small and only having two UI concepts? 

Is it worth setting up as multiple modules in an application now and later moving each module into its own application, or is it just as easy to straight to multiple applications? 

What are the complexities I should expect as I split a module into multiple modules (or applications) or as I convert a module to an application?

Thanks again.

Solution

To me, the downside is a little more complexity: you're ballooning the number of applications that you'll work with and while you get an overall image of the relationships between your business concepts, you'll still need to manage them and make sure you don't have too many central dependencies. Separating your concepts is helpful but you'll still have to mind your deployments if one of your applications is consumed by twenty others. You might also note that some of your modules/applications are a little sparse on content as you fill out and separate code, but it's easier to delete superfluous modules than it is to refactor and create new ones from scratch.

I think it is worth it to do it as early as possible because of two reasons: refactoring is always more painful the later you do it, and should you deploy your applications to testing and production environments, it's best to do as few module moves/renames as possible, since this might cause issues when deploying.

Splitting modules and spinning new applications should not give you any issues, but be careful when renaming/reusing module names, especially within the same application and if you've already deployed the application to other environments - you might get errors as the platform attempts to manage the module/application unique identifiers and there can be mix-ups.

Solution

Thanks so much.