Reading time: 2 minutes.
Mere color, unspoiled by meaning, and unallied with definite form, can speak to the soul in a thousand different ways. –Oscar Wilde
After 600 hours of OutSystems online training and the Associate Developer Certification, it was time to do some real work.
My first OutSystems project consisted of a 300 Application Objects solution around Business Processes, with relatively different challenges:
- Plain Old CRUDs
- Several types of users, with different sets of functionalities
- Integration with Elasticsearch and other cloud available services
- BPTs for business and technical needs
- Jobs / Timers
- .Net extensions
- Dashboards & reporting
- Specific UI/UX
- Dummy data generation
- Automated testing
- And so on…
After several interactions / sprints, it was time for some refactoring, following the precious advises from the Module Naming Conventions and Architecting Sustainable Applications courses, with the help of the Discovery Tool and supported by the three golden validation rules:
- No upward references
- No references among orchestrations or end-users
- No cycles
With a couple of days of deep work, we reached an architecture with all the concepts well organized, modules easy to reuse, capable of having independent Business Owners per application and no breaches regarding the above rules:
Discovery tool canvas with all our modules
During the process we felt the need to have some Studio support so we could easily identify at any moment the kind of module we’re dealing with. It’s something not new – we found several ideas on the OutSystems community regarding this need:
- https://www.outsystems.com/ideas/2459/tint-service-studio-tab-interface-based-on-architecture-canvas-layer-standard-col
- https://www.outsystems.com/ideas/1559/prevent-architecture-pitfalls-directly-from-servicestudio
- https://www.outsystems.com/ideas/1455/dynamic-high-level-architectural-design-diagrams-at-application-selection
With no alternatives besides the naming conventions, we tried something very simple but efective – module icons with the color of the corresponding architectural layer.
Dark blue – orchestration
Light blue – end user
Orange – core services
Green – libraries
The result from the Studio perspective was:
In the explorer side pane is possible to see the type of module we’re dealing with and all the dependencies.
When modeling the flows, is possible to see the type of actions we’re using.
When adding or changing dependencies, is possible again to see the kind of modules we including.
From our perspective the gives us two good advantages:
- You see the architectural layers in the most used screens of the OutSystems Studio
- Makes it easier to identify the type of module were dealing and if we’re using or including functionalities from the correct layer
Some might argument that you shouldn’t do any development without having those worries in mind and is not the colors of the icons that will make a huge difference.
Nevertheless, teams are made of humans. Teams have different levels of experience and expertise. Teams have pressure and tight deadlines. Teams have elements that sometimes don’t sleep at night because of a sick child. So all the help to remind us of the important things is always welcome. That’s why we’re going to keep using these colored module icons.
What do you think?
PS: I really recommend the Architecting Sustainable Applications courses. It made a huge difference in the way I see the OutSystems platform and how solutions should be built. It made me enjoy (even more) this technology!
Photo by Alex Holyoake on Unsplash