Software Architecture

Today I will talk about chapter 14: "Software Architecture: Laying the Foundations of Software Design" from the book "Code Craft: The Practice of Writing Excellent Code.", by Pete Goodliffe.
This term 'software architecture' is certainly extremely difficult to define since it is a relatively new topic and for these reasons it has not been possible to define a definitive version for its meaning.

In general we can say that software architecture is all about the plans behind each project and it is necessary to understand how every single individual part works on the system so we can know how the system should be extended over time.
I think an important thing to know is that system architecture is used to validate what is going to be built, communicate the design to all interested parties and discriminate which helps us when making decisions.

We must keep in mind that a good architecture is based on simplicity and needs to be comprehensible. Some examples that I read about are the spaghetti ball architecture, which is a messy, uncontrollable, unmanageable morass of interwoven gloop architecture or Lasagne, which is several distinct layers, arranged one on top of another. There is another type called cannelloni, which is good conduit for its contents, suits situations very well.

Software architecture is a very important and very complicated branch of computer science, complicated because nobody teaches you how to be a software architect, and only the experience as a developer, administrator, tester and other areas will give you the necessary knowledge to be a good one.

Comentarios

Publicar un comentario

Entradas populares de este blog

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
Leer más

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
Leer más

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
Leer más