Software Design and Architecture 2017-13

Done. We have read through all Ready Player One novel, and leaving all the plot twists and awesomeness aside, there are lot of ethical matters in the wind, let´s try to land them on this blog post, shall we. First; technology dependence is a real thing. While not as notable as seen in Ready Player One, technology is beginning to take an important place in most of our lives, however, a balance (or at least, limits) should exist. I do personally see systems like OASIS materializing in a distant future. The closest thing I personally know is Second Life, an online virtual world, where many people involve themselves in education, business, social, and real estate matters. Even some people make real money out of working inside the virtual world through their avatars. I don’t know if something intrapersonal has happened inside that simulation, but I think that different types of cultures may sprout from inside the system, so I believe that our value system could be altered if we

After reading the article, I started relating microservice architecture with the activity we made when we talked about components and Lego bricks in class: This type of architecture is made of smaller and independent services that are linked together to form a concrete service. With the image below, we can see a clear representation of how this is conceptualized. However, there is a small detail that separates microservices from monolithic services; while the later gathers all functionality into a single process, the microservice separates each part of the functionality into a separate service, allowing scaling with distribution of the services, replicating as needed. This is the aspect I liked the most; low key planned modularity for software architecture (or at least that’s how I see it) There are a lot of interesting features of this type of architecture (with a heavy approach to encapsulation, as I dare to confirm), such as Componentization via Services, Organized ar

So, this blog is about the “4+1” view into architecture. Why is it called that way? Why not only 5 (as, for what I have learned, 4+1 equals 5)? Well the concept in which this type of view rose is the key. What this type of view proposes are 5 grouped different types of views; Logical, Development, Process, Physical, and Use-Case. The logical view explains us what sort of objects are we going to be building, such as classes and objects, and how this object act within the system logistics. However, the scope of this view is limited only to the implementation of the system. The second view is the development view, which is aimed towards developers explaining how the system is organized. With this in mind, the developers will be able to recognize which parts of the system are connected to which. This consideration allows the developers to work with the system under development. This view is only focused on the organization of the system development. The process view desc

So, we are talking about SOLID in this blog post. No, not our favorite state of matter (that should be plasma, of course) but a group of five principles of object-oriented programming and design. SOLID covers how to program better and cleaner through different principles. I think that these 5 principles come together and forms a “solid” foundation on what and how needs to be done (it took me some days to think of that pun). The first principle may be pretty straight forward, however, it is often overlooked, leading to the start of some messy code; every class should have exactly one responsibility. While many people avoid following this principle and starts delegating responsibilities to functions inside a class, this can lead to confusion of how a specific class works, and the design of the whole project may start to crumble. The open/closed principle allows us to make classes ready to be extended if needed, but be closed to modifications, this avoids fragility to the o