Hello and welcome to architecture basics in the OutSystems platform. So, why is
architecture such an important thing? Why is it such a big deal? A good
architecture will allow you to manage the complexity of your application
enhance the visibility of all the parts that make up your application
therefore allowing you to better plan further developments.
It will also facilitate change, make changes easier, reduce the risk and
increase the development speed, because it will be easier to split work across
different people. So, how do you go about achieving a good architecture? It is
important to think in a modular way when you're developing code. So what is
modular programming? It's a design technique that separates the
functionality of a program into independent modules and now each module
in turn contains all of the code, all of the logic, all of the data to carry out
one specific function, or one aspect of the functionality that your application
has, so it's a divide-and-conquer approach. There are many benefits to
modular programming: on the programming side you get to have better abstraction and
encapsulation, this means that you're able to solve just one problem,
one challenge, implement one functionality, at a time.
Furthermore through the encapsulation, you're able to define what is meaningful
to the outside system and only expose those parts: you're able to hide away all
of the internal complexities that this module might have and not broadcasted to
the outside.
This means that some of your modules will actually not be full-blown
applications, rather they will be libraries, they will provide
functionality to be used by other applications. There are also non
programming benefits to a modular programming paradigm: one of them is the
optimization of the publication in deployment process
you don't need to recompile everything, you just compile the modules that have
been changed. Furthermore there are work breakdown benefits, if you have different
modules that are specialized about different things you can get different
developers working on them and it allows you to better break down the work
between every developer. So, how do you achieve modular programming in
OutSystems? Your full application is actually made up of several modules, each
module can opt to share certain elements inside with other modules, in OutSystems
language these are called public elements. Every module that shares at
least one feature is called a producer and every module that borrows one
feature from another module is called a consumer. Obviously you might have models
that are both producers and consumers. So of all the things that an OutSystems module
can have, what are the elements that can be made public?
Well, on the data side of things you can make entities and structures public
entities in particular are a very very common pattern to use and to make public.
In the larger side of things you can have actions and rolls and again, if
you're building a library it's very common that you make actions public. In
the interface side of things, you can make public web blocks and screens. You
will find that web blocks are much more commonly made public, for example
when you create your own widgets they will very likely be created in a
centralized library and be exported as a web block. Now after you made your element
public and published it to the server
how can you go from another module and borrow that functionality?
Well, you access the manage dependencies window from service to you, in this
window you will be presented with the list of every single module on your
server that has at least one public item. To actually consume that item from
that producer you just simply need to tick the checkbox next to it - after you
press ok and you come back to edit your module you'll be able to use every
single element that you borrowed
exactly as if they had been defined in the current module, so for example, you're
able to do queries over entities that you've consumed from another module and
you'll be able to call actions that you have also borrowed from another module.
When you publish a producer effectively you're committing to your server a new
set of entities, new set of code. It is important then to refresh this code in
the consumers. The way to do so, is open every single consumer go to the manage
dependencies window and refresh the icons that show that this producer is
outdated. You should be particularly careful while architecting your
applications so that the modules don't consume other models who in turn consume
themselves
therefore creating circular references. So, what are some of the cases where
modularization comes in handy?
Let's look at a few patterns. One of the scenarios is to group all of the screens
that together implement one particular business process.
The other case is to wrap an integration with an
outside system therefore hiding away any specifics of the runtime of that external
system. Another very common pattern is to wrap business concepts, wrap every single
entity that together works for a particular functionality of your
application.
So for example, you might have every single entity, every single piece of data
that deals with orders and order management in a particular module, you
might have everything that's related to an employee, say for example, his vacations,
his contract stuff also wrapped around in one particular module and generally
speaking
every time you have some concept, some functionality that is of
high reusability you want to move it to a dedicated module to be used by many
applications. Now, this was all just scratching the surface of architecture,
of modularization: if you want to know more there's a couple of links on this
slide, and in particular I want to call to your attention the very last link that
gives you more information about the four layer canvas. The four layer canvas
is the de-facto standard way in which we at OutSystems break up the modules
that make up our applications. If you want to know more about the patterns and
the names we give to the patterns, and how we spread them across the several
layers of an application, you should look into this particular link. And that's
basically it for the architecture basics. See you in the next lesson!