The 4-Layer Architecture in Practice

Editor's Notes

• #2: Welcome to my presentation about the 4 layer canvas in practice.
• #3: My name is Marlies Quaadgras and I work for Transfer Solutions. I have more than 30 year experience in software development and testing. The last 3 years I have worked with outsystems. In different ways. Alone on a system, as “Delivered hands” in a big project, and as techlead.
• #4: These are the experiences that our team had with the 4 layer canvas, and the lessons we have learned about it. So for us it was the best architecture, and i will tell how we got this architecture
• #5: One of the statements I often use is “Learning from trial and erro”, or in dutch “van proberen kun je leren”. When I was on a solo project, I had to try a lot of things before it worked fine. Now I can do those in 2 minutes, but then I was trying 2 3 days to find out. Or just out of the box, if it does not work this way, lets do it the other way around. But now I know exactly what works and what does not work.
• #6: First i am gonna tell you some theory about the 4 layer architecture model. The theory about the model as Outsystems described it Then about the architecture that we choose for our systems, and the vision we had about it How we implemented the new architecture and the lessons we have learned
• #7: So let start with the theory behind the 4 layer canvas
• #8: Modular programming leads to this structure of modules. You don’t want a monolith structure They are all modules in outsystems To make a good architecture you have to orden it and use logica to put the domains that belong together in the same module. Also put the units that have the same function in the same layer
• #9: BEST PRACTICE FROM OUTSYSTEMS 1. The Orchestration Layer contains the processes, dashboards and the portal so it allows the user a unified user experience 2. The End User Layer contains the user interfaces and user processes. The user stories are implemented here. The screen that the user sees 3. The Core Layer contains the entities, the business concepts and business rules that are used in various End User Layers. When you sport, you do some excercises for you core, it’s the base of everything. 4. The Foundation Layer is business independent and includes Menus, UI patterns and communication with external systems. No data
• #10: The 4 Layer Canvas is an OutSystems architecture method in which a server-oriented structure can be designed. With this architecture, relationships and references of the modules can be properly managed, which enables the possibility partial deliveries take place.
• #11: 5 The 4 Layer Canvas is an OutSystems architecture method in which a server-oriented structure can be designed. With this architecture, relationships and references of the modules can be properly managed, which enables the possibility partial deliveries take place.
• #12: Clear ownership of modules Different developers can work on different modules
• #13: Possible partly deliverances. So in case that a hotfix needs to be done just some modules can be deployed
• #14: So how did we started the project.
• #15: It started very simple. According to the customer is was about 6 weeks work for 1 person. I was that person. The customer would deliver the functionalities that I had to make. We did not had the exact functionalities before we started, but assuming the customer made a good estimation, We choose a simple structure. In one application, just one module in the end user layer, and 3 core layers. The menu and the theme were placed in the end user layer.
• #16: It became apparent that a lot of merging needed to be done while publishing. So we stopped developing in order to create and implement a new architecture
• #18: This is the result of how we split the modules Modules contain information of the same functional area
• #19: How do we decide to split? Modules contain information of the same functional area. For an order you need orderlines For a product you need statistics about how often the product is used in orders Product not only contains the product entity, but referential entities like a product picture, pricelists, product group
• #20: How do we decide to split? Modules contain information of the same functional area. Related entities like ProductImage, ProductGroup, ProductPrice , ProductAvailability Wrappers because security, so that the entity actions are not called themselves Serveractions like changing status of the product, or the availability Simple webblocks like you always want to display the number and the name of the product together
• #21: Webscreens like ProductList, ProductDetail, ProductPriceOverview
• #22: Library module: Menu, theme roles
• #23: Core layer: The entities, and the server actions that are specific to the entities and the crud actions The entities with the same functional purpose can also be found here. If there's an entity that has a many-to-many relationship with two entities that will be placed in two different modules, this entity cannot access one of the two modules because then there will be side-to-side references. Separate Core Layer modules must be provided for these entities. When no webblocks are involved, we can user service modules
• #24: End User Layer. The web screens and web blocks are divided based on their functional purpose. If a web block is invoked in multiple web screens, this web block is placed in a separate module in the Core Layer, and not in one of the modules that the web block invokes. This is to prevent side to side references. These modules also contain business rules, which are implemented as server actions and specifically relate to the functional purpose of the module.
• #25: Development backoffice: First test webscreens not in the menu but accessible by the developer, later these are placed in the development backoffice Dashboard; just one webscreen contains webblocks for all the necessary information
• #26: So how did we implement this new structure?
• #27: Before we started, we took the following conditions: no functionality is added. That logically, but you tend to change something while you see it. That is why we were working in pairs, so made sure you don’t do anything wrong. Of course you can go back to a previous version, but it is better to do it right immediately remove test data: since the project was now only 2 months ahead, we had no solid test data. There was some corrupt data, made by versions that were not right at the start, so there was no problem that those data was removed. We searched for tools to keep the data, but that offered too much effort for a little profit. For test purposes, it is a good opportunity to clean the database and add new test data. Use discovery to keep the changes in track, and act immediately
• #28: Before we started, we took the following conditions: no functionality is added. That logically, but you tend to change something while you see it. That is why we were working in pairs, so made sure you don’t do anything wrong. Of course you can go back to a previous version, but it is better to do it right immediately remove test data: since the project was now only 2 months ahead, we had no solid test data. There was some corrupt data, made by versions that were not right at the start, so there was no problem that those data was removed. We searched for tools to keep the data, but that offered too much effort for a little profit. For test purposes, it is a good opportunity to clean the database and add new test data. Use discovery to keep the changes in track, and act immediately
• #29: At first we started with the core modules. That was the most difficult. We needed to split one module in one to many modules, so we could not use the way as it was described here. As I said, we did not need to keep the data, so we just copied the entities and the crud server actions to another module. We made them public and then published the new module so that they were saved. After that we removed the entities and server actions from the old module. That lead to a lot of errors. By setting the dependencies to all the items in the new module, all or most of the errors disappeared. The few that stayed needed to be checked one by one. When there were no errors the module is published. After publishing we removed the unused dependencies, to have a clean module, and then publish it again.
• #30: Before we started, we took the following conditions: no functionality is added. That logically, but you tend to change something while you see it. That is why we were working in pairs, so made sure you don’t do anything wrong. Of course you can go back to a previous version, but it is better to do it right immediately remove test data: since the project was now only 2 months ahead, we had no solid test data. There was some rotten data, made by versions that were not right at the start, so there was no problem that those data was removed. We searched for tools to keep the data, but that offered too much effort for a little profit. For test purposes, it is a good opportunity to clean the database and add new testdata. Use discovery to keep the changes in track, and act immediately
• #31: After that the end user screens were easy. We copied them to the right module. To avoid side to side references, web blocks that are used in 2 screens in different end user layers are copied to new modules in the core layer. Do not use the module name itself, but use the external URL The menu and the roles are copied to the theme module. Also here the external url is used, to avoid upward references.
• #33: First it was a small delay but a big success. We used one sprint to figure out how we could split and the perform the actual split. No functionality was added. The next time I would define a lot more modules, may be if they only contain just one entity and its server actions, to avoid this again. But you always need to know in advance how big the system will eventually end up and what extra functionality may be will be added To avoid side to side and upwards references, use discovery frequently during the process. Always define the right colors for your system, and leave the modules in outsystems that are not in your system grey. Then you can see immediately if the architecture is ok. For test purposes, it is sometimes a good opportunity to start with a new clean database that you can fill with your own test data, instead of going on with may be rotten data.
• #34: First it was a small delay but a big success. We used one sprint to figure out how we could split and the perform the actual split. No functionality was added. For test purposes, it is sometimes a good opportunity to start with a new clean database that you can fill with your own test data, instead of going incorrect data.