S/W Design and Architecture

I liked a lot the two videos and the reading of this week, all aimed to teach the lesson that there are some things that are really big for one to understand alone. Perspectives are the most important part of dealing with a  complex problem. The worst thing one can do is to think that their perspective is the only one that exists. This is specially true for systems architecture, according to the video of the 4 + 1 views any complex architecture instead of seeing it as a whole. Each view represents one important part of the whole system and it is easier to explain than to explain it as a whole. The 4 main views are: Logical: Structure and functionality. UML: Class, Communication, Sequence. Process: Process and communication between them (dynamic). UML: Activity. Development: Management of software artifacts. UML: Packages, Components. Physical:  Topology of the physical part. UML: Deployment. There is an extra view, the most important one in my opinion. Use Case: System as

This week's reading was basically to understand the SOLID principles. Which are: S ingle Responsibility: A class or method should only do one thing and one thing only. O pen/Closed: Once a base class is done there shouldn't be any modification at all, only extension. L iskov Substitution: You should be able to change a base class for one of its child at any given point when referencing it. I nterface Segregation:  Have several small interfaces instead of one big interface. D ependency Inversion: Instead of using concrete classes use interfaces inside classes to avoid depending on a concrete class. These principles were presented first by Uncle Bob but the name was coined by Michael Feathers. The main theme of this principles is to avoid dependency while programming, to make the code complexity as simple as possible.

Microservice architecture is a handful approach for cloud development, basically it eliminates the idea of having a monolithic architecture and instead having small components that communicate themselves through simple protocols. The truth is that micro services are very good for implementations that require to be constantly updated but not as a whole. It also helps to protect data by decentralizing it. As such the problem is that businesses are abusing of this services idea and create a lot of unnecessary services in my experience, although the concept is very appealing if the problem can be easily solved with a monolithic architecture, it should. One should not create services just for the sake of the mode, one should create them because it is easier to work with them, not incredible difficult to maintain.