Software Design and Architecture - Emiliano

 Logical View Se encarga de ver la funcionalidad. Por lo que entiendo, normalmente se representa con diagramas de UML tales como diagrama de clases y diagrama de estados. Se enfoca en lo que le corresponde al usuario.  Process View Se encarga de ver como funciona el sistema al momento de ejecutarlo. Explica las comunicaciones entre el sistema y los procesos. Se usan diagramas tales como diagramas de flujo y diagramas de comunicación Development View Prioritiza la vista desde la perspectiva del programador. Corresponde a la administración de software.  Implementation view es otro nombre para esta vista.  Utiliza el diagrama de componentes o paquete de UML Physical view Se enfoca de un ingiero de sistemas. Topología de los componentes de sofware y las conexiones físicas entre estos. Deployment view es otro nombre Deployment diagram se usa del UML  Use case view Define los casos de usos. Este representa el +1 en el nombre del modelo. Interacciones y procesos son de...

 Single responsability This helps a lot when tyring to define how a service, class, object should work. Not defining a single thing that the object is responsable makes it really easy to have overcharged classes that do everything all at once. Making the code completly unmaintainable. And do not confuse responsability with single thing to do or single action. It means the object is only responsable for this specific thing. Open/Closed  This, to me, means that when modification to add functionality. The best course of action is to add other inheritable classes insted of modifying base class. Liskov substitution This means that child and parent should behave as expected. This means that having a base class T and an S class that inherets from T, you cannot somehow change how T behaves, because you need to be able to usse S instead of T. Interface segregation Make modular simple interfaces rather than a huge oversized interfaces with all possible methods. Classses shouldnt need to...

 The microservice architecture is definitly one which I wish I knew before. Having worked on a monolithic product for quite a while it has been proven to me that those kind of projects grow really fast. Having the ability to develop, produced, deploy and scale different products or process independently is somthing highly attractive in my eyes right now.  And this is not only for the purpose of making a project modular. The miccroservice architecture activly supports introducing new frameworks and technologies and developing only for the process and not the entire product. Along the lines we can see how this activly pushes for a better design, not only in the developing thing but also in the business side.  To sum up everything that has been stated so far. I think the microservices allows for a healthy grow of a given product, makes it modular and loosly coupled, and promotes healthier business side logic. However, a big red flag that i can see in this is not preparing an...