Entradas

The 4+1 View Model

Today I will talk about the resources related to The 4+1 View Model, two Youtube videos and one article named The Elephant and the Blind Programmers by Grady Booch. These videos and article speak briefly about the 4 + 1 view model, this small model consists of four sections and an additional section that is part +1, which allows us to make a better software architecture. Let me explain these views: - Logical view: This view tells us what kind of objects we are going to build, how they communicate and what kind of data they are. - Development view: It is useful for developers to always know which part is related to what else and how things are organized during development. - Process view: describes the concurrency and synchronized aspects in the software and the process of using the software or doing things. - Physical view: It tells us how the software and the hardware are related. - Use cases or scenarios (+1): They are the explanation on how the system is expected to behave, w

Understanding the SOLID Principles

Today I will talk about the Edward Guiness’ book section titled “Understanding the SOLID Principles”. First of all Solid is an acronym that stands for five principles of object-oriented programming and design. These principles help to avoid dependencies between the classes. S-Single Responsibility Principle O-Open/Closed Principle L-Liskov Substitution Principle I- Interface Segregation Principle D-Dependency Inversion Principle Talking a bit more of these principles we are going to explain each one: Single Responsibility Principle: This principle states that one class should only have one responsibility so the changes in that class do not end up affecting unrelated critical features on the system. This happens from a single action to a set of processes. You can take a view that a single responsibility refers to a group of related business processes. The stamina and tolerance determine how far you go Open/closed Principle: This principle talks about that classes should be op

Microservices

Today I will talk about the article “Microservices” by James Lewis and Martin Fowler (March, 2014). This term is used to refer to a way of designing software in small independent services that will work together. This is used mainly in business applications and has some peculiar characteristics.     In other words Microservice Architecture means, a microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with each other. These services are built around business capabilities and are independently deployable.     Microservices have a great advantage over a monolithic application, because this style does not put all the functionality into a single process, and  if you want to make a change you do not need to rebuild the application.     Of the most interesting things that this design pattern has is that each microservice can be seen as a black box, and thus remove a bit of the comp

Software Craftsmanship

Today I will talk about the podcast titled “Software Craftsmanship”. This podcast is about agile software development and software craftsmanship. It was an interview with Robert C. Martin, who is a software engineer and author of a lot of books better known as the uncle Bob.     The first thing we hear is Uncle Bob talking about his experience of being a software architect. We also hear him saying that the worst part is the people that tend to separate architects from software developers. He believes it is weird because architects make decisions about the code and have no familiarity with it.     Robert Martin, talks in this interview about software craftsmanship and he tells us that is a concept that says that every young coder or developer  needs to have a master because we can not learn coding just with theory, you must help another person to learn, in a project or whatever you want but help someone. This is similar to attending college, here you have classmates that maybe have

Hidden Figures

Today I will talk about the amazing movie titled “Hidden Figures”. Normally in those times they didn’t recognize all the women were part of important projects and this movie is one example of how they used to hide the work from the matchless Katherine Johnson. I can say that it has become one of my favorite movies.     The film tells the story of three African-American women who worked for NASA in the early 1960s, collaborating in an important space program. These brilliant women achieved incredible goals that seemed impossible because they were women and African-Americans.     What impresses me about these women is their intelligence, their strength, their perseverance and their struggle that allowed them to demonstrate that they were more than capable of being involved in areas that were considered suitable only for the masculine intellect, such as science, mathematics and engineering.     I can identify a little with those great women of that movie, not because of how brilliant t

Is Design Dead?

Today I will talk about the article Is Design Dead? by Martin Fowler (May, 2004). I think it is important to design first and then code, this will avoid the code and fix. Also, the quote that says “if you listen to your code a good design will appear” it doesn’t make sense. It is very interesting to know that there are two styles of design.     The most common and disastrous is Evolutionary Design, as the design of the system grows as the system is implemented, this style makes it difficult to change the system. On the other hand, we have the Planned Design, here the designers don't need to write code because they aren't building the software, they are designing it, in this way, they avoid entropy by making decisions and carrying out the development of the software.     Although the second style is much better, it still has faults, not designing and coding at the same time, it can introduce complex problems in the programming stage. The other fault, which I found quite inte

Who Needs an Architect?

Today I will talk about the article “Who Needs an Architect?” by Martin Fowler, published in IEEE Software. It seems that Martin Fowler and many other people do not agree with the definition of architecture as a high-level design, who tells us there's no highest level concept of a system. The best definition they propose is the following: “In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture.’ This understanding includes how the system is divided into components and how the components interact through interfaces.” Sounds better to me, because it makes clear that a lot of people are involved in the construct, or in simpler words of the author: architecture is about important stuff.     According to the article an architect should be defined as someone that worries for the important stuff, someone who takes important decisions, must be aware of what i