Software Design and Architecture

In this blog, I will discuss the article titled "Microservices" written by James Lewis and Martin Fowler in March of 2014. I found the article to be interesting and shed some light to things I didn’t know about microservices. Microservices are a type of architecture that structures applications as a bundle of different services. What's good about them is that they allow for continuous and efficient deployment of applications into complex systems. So their implementation is often vital when working on a problem that requires a large subset of tools and resources in order to work, meaning that this system is complex and big in size. What microservices accomplish is that it allows companies and different application services to widen their stack of technology and enable the continuous delivery and deployment of technologies into their systems. Companies tend to apply microservices when their systems grow largely and become more complex. This allows the system to becom

In this blog, I will discuss and review the videos called "4+1 View Into Software Architecture" and "Six Blind Men", as well as the article titled "The Elephant and the Blind Programmers" by Grady Booch written in 2010. Often times when developing, we don’t take into consideration the interactions users will have into our system and in doing so, we degrade the experience of what we build. The interaction can vary from user to user. That's what we see in the video where the blind men interact with the elephant. Their interpretation of what that elephant is like varies because of their different perspectives and because they chose different parts of the elephant to make that judgement. And that's all good, because having a different interpretation doesn’t mean they are wrong. Because the combination of their interpretation defines what they experienced very well. In the end they gave a very clear description, although abstract, of an elephant.

In this blog, I will discuss a section from the book "Ace the Programming Interview: 160 Questions and Answers for Success" by Edward Guinness published by Wiley in 2013. The section I will discuss in this blog is called "Understanding the SOLID Principles". So first of all what does SOLID stand for? It stands for: S ingle Responsibility Principle O pen/Closed Principle L iskov Substitution Principle I nterface Segregation Principle D ependency Inversion Principle Lets try to briefly understand what each of this mean. Single Responsibility Principle: Like the article says, a class should only have one responsibility and there never should be more than one reason for the class to change. One good way of applying this principle is asking yourself whether the logic you are coding into your class should live there or not. Open/Closed Principle: This principle states that software entities should be open for extension but closed for modi