As I continue my journey with Outsystems  (and web development in general) I am often left wondering if I'm doing things the proper way.   I have reviewed documentation on the 4 layer canvas.  I think I understand the general concepts, but I'm wondering what the if there is a best way to execute it?   The library and core modules are the most logical to me, but when I get to end user and orchestration it becomes more fuzzy.

If I have an application with 10 screens do I make each screen its own module/web block?   Then in the orchestration module do I pull in all of those web blocks to form the final product the end user experiences?   Does anyone have an example project that they can share that shows how this all really comes together as a functional page?   

I need to avoid circular references so my pages shouldn't "know" about  each other and I know I can use the getEntryURL function to handle all of the links as external URL but I doubt that this is the best way forward.   

Thanks in advance for any guidance provided.

Hi Josh!

The Outsystems documentation give us the general guidelines, and I think that in practice, each one should take some reflections about our needs and apply what works better for the case. I'll try to answer yours questions telling  you what we are doing here, but as I said it's not a general rule.

In 4 layer canvas end user layer we put all modules that contains screens for an application, like CRUD screens or a screen that execute some action in the application; each module group screens for a specific domain. For example,  for an application that have final users (like costumers) and admin users, you could have two end user modules, grouping screens that belongs to each module. In orchestration layer you could have modules with screens that contains dashboards or information like a portal linking to end user modules screens.

Talking about circular dependencies, I think that the use of getEntryURL it's not a issue to worry about, because it belongs to system module; circular dependencies is about references between modules.

Use use these components to help:

Eletronic Canvas: During design time we use this component to define application architecture, and all modules.

Discovery:To monitor environment's evolution and care about circular dependencies.

Help this helps someway.



Okay i think I’m following along.   One end user module with all screens for each user group...but if you go that route how do you handle multiple developers working together?   I assumed each screen would be its own module so you don’t have multiple people working on screens within the same module at one time.

Multiple people working on the same modules (different screens) is not an issue; the platform makes a merge and it works properly. Many developers working on the same screen came more complex though; although platform act at the same as before (making a merge), in this case the automatic merge can't decide about many modifications, and this cause a extra job to mark which one should be deployed (conflicts in the merge).



Thanks again, I think our team wants to modularize more than just a single end user module containing all of the screens.   So now I'm thinking about splitting screens into different modules and then developing each screen as web blocks.   Then create a view module which pulls all of web blocks in, I just worry that we are going to run into issues down the road if we go this route.

Hi Josh,

I think that there is no silver bullet and you would try it and change what not works properly. I'm afraid only about the approach to make all screens using web blocks. I think that you should select what can be reusable and make it as web blocks and build others as simple screens. Web blocks are more complex to develop, maintain and debug, so, if it will not be reusable, I don't see benefits on it.



Hi Josh,

Sorry for going back a bit here, but what documentation did you review to learn about the 4 Layer Canvas?  Was it docs or was it the Architecture Guided path in the Training area?

The Designing an Architecture course (in the Guided Path) walks through an example scenario that shows various architecture decisions being made using the canvas.  The Style Guide Architecture course may also be helpful in determining how to split up some of the Front-End elements into modules.

You seem to be concerned about having more than one developer working in the same module at once.  This isn't really a problem if they aren't working on the same elements.  If each developer is working on a different screen then they shouldn't encounter collisions much and can do simple merges when they publish.



I was looking at this information, and it is useful but I was hoping there would be an example project that could be downloaded and reviewed to see an example of concept to reality.

I think my biggest struggle with multiple developers working together stems from the fact that previously I have been the only developer on my application, so the thought  of having many people collaborating worries me.   It's just something I'll have to work through.    

I do wish Outsystems integrated with Bitbucket though so we could easily see who changed what and when.   I know there are versions saved on the server, but in a given day each person might publish 100 times as they tweak things and I would love it if there was some way that the work could exist in their own private version and when finished and polished could be committed to the development branch.