Entradas

Mostrando entradas de abril, 2020

2-5: The 4+1 View Model

So, in order to understand the 4 + 1 view model we need first to define the components of this view model. In this case, the components of this view model are the following ones: Logical view, Process view, Physical view, Development view and the +1, the Use Case view. Having this in mind, let me define each one of these views in order to fully understand this view model: Logical View: Shows the parts that comprise the system, as well as their interactions. It also represents a set of abstractions and emphasizes classes and objects. This view can be represented with the following UML diagrams: class diagrams, state diagrams, object diagrams, sequence diagrams. Process View: Describes a system's processes. It also shows any communication between those processes, explores what needs to happen inside the system. It is particularly helpful when your system will have a number of simultaneous threads or processes. This view can be represented with the following UML diagrams: ac

2-4: Understanding the SOLID Principles

The first thing that came to my mind when I read the title of the lecture was, what does SOLID stands for? So, first let me contextualize what is SOLID and then explain the meaning of all the letters in this acronym. As I said before, SOLID is an acronym that stands for five principles of object-oriented programming and design. The objective of these principles is the avoidance of dependencies, because the more things you depend on, the greater the chance something will go definitively wrong; these 5 principles are the following ones: S => Single Responsibility Principle (SRP): States that a class should have exactly one responsibility. This means, that it should have exactly one reason (or one class of reasons) that cause it to be changed; nevertheless, many programmers have the superstition about the systems they maintain things like "Don't touch this module" or the difficult task of selecting that single responsibility. O => Open/Close Principle (OCP): St

2-3: Microservices

We can define Microservices as an architectural style which approach is to develop a single application as a suite of small services, each of them, running its own processes and communicating via lightweight mechanisms, often Microservices uses an HTTP resource API. We also need to compare a traditional monolithic application in order to compare and to give a better explanation of what is a Microservice. A monolithic application puts all its functionality into a single process and scales by replicating the monolith on multiple servers. But, microservices do not work like this, a microservices architecture puts each element of functionality into a separate service and scales by distributing these services across servers, replicating as needed. Having this context, we can have a better idea of what is a Microservice. Now, it is time to enumerate the important characteristics of a Microservice Architecture, have in mind that it does not exist a silver bullet in development so, no