DEV Community: Victor Hugo Grabowski Beltramini

Introduction to Message Brokers

Victor Hugo Grabowski Beltramini — Wed, 09 Mar 2022 01:40:30 +0000

Key definitions

A key feature used in many software designs and architecture are the messages brokers. A message broker is a cross-application communication technology that helps build common integration mechanisms to support cloud-native, microservices-based, serverless, and hybrid cloud architectures.
Message Brokers enable the programmers to build applications, systems and services to communicate with each other and exchange information. On that same process they can validate, store, route, and deliver messages to the appropriate destinations.
To provide reliability they often rely on message queue structures where they store the massages in order until they are fully consumed by the application. So they will normally follow a FIFO(First In First Out) method to organize and process the queue in order to process all messages that are in the queue

Message broker models

Peer-to-peer messaging

This is the distribution pattern used in message queues with a one-to-one relationship between the sender and the consumer of the message. Each message in the queue is sent to only one recipient and processed only once. This method is used when the message only had to be executed once
- A good example for this messaging pattern is a payroll/financial transaction processing. In these kinds of systems, both senders and receivers need a guarantee that each payment will be only be process once.

Publish/subscribe messaging

In this message distribution pattern, commonly referred to as "pub/sub", works with the idea that each message is published to a topic, and all the multiple message consumers that are subscribed to the topic will/want to receive those messages. All messages published on a topic will be distributed to all subscribed applications. This is basically a broadcast distribution method where we have a one-to-many relationship between the publisher of a message and its consumer.
- A good scenario and example where we can use this kind of message distribution pattern will be in an airline company where they will have to release updated information about the flights, and that information could be used by multiple systems since ground crew performing aircraft maintenance, refueling, baggage handlers, flight attendants, pilots preparing the aircraft for the flight, operator visual displays to inform the public, and many others possibles systems

Here we have a more basic visual example of how does work those mainly used message broker models

Data Structures: Introduction to Trees

Victor Hugo Grabowski Beltramini — Wed, 09 Mar 2022 01:21:25 +0000

So first of all Trees are a data structure that is used to store data in a hierarchical format, so trees are not a linear data structure. We can define a tree also as a collection of nodes where each node will contain a data value and a link to others child node.
In trees we do not store data in sequence, trees will store the data in multiples levels and multiples nodes.

Important terminologies

Root
In the trees the first node will always be the Root Node. Every tree will have one and only one root node, we also can say that the root is the origin in this kind of data structure.
Edge
All links between the nodes of the tree will be called as Edge, and in a tree with 'N' number of nodes will always have a maximum of 'N-1' number of edges.
Parent
The predecessor of any node is always called as Parent Node.
Child
The descendant of any node is called as Child Node
Siblings
All nodes that have the same Parent are called as Siblings, in other word all nodes with same parent are called Sibling nodes.
Leaf
All nodes that doesn't have a child node are called as Leaf Node.

Software Architecture & Software Design

Victor Hugo Grabowski Beltramini — Tue, 22 Feb 2022 16:18:55 +0000

Software Architecture

Fundamental organization of a system, or the way the highest level components are wired together.
It's how you organize your softwares components to then be more easily maintainable and to be easy to add new features
Design decisions that need to be made early in a project
“Architecture is about the important stuff. Whatever that is” - Ralph Johnson.

An architect has to be able to recognize what elements are important, recognizing what elements are likely to result in serious problems should they not be controlled.

Hexagonal(Ports & Adapters) Architecture

The main idea when using this architecture is to isolate our business logic, to do that we can use ports and adapters to have request send to our core of the application.
A simple example is when you will have a system and your account can be created from a few different places like an API or the system interface, but both will end up in the same main business logic of the application.

Primary adapters are the entry point of our application like a http request, an API or some other type of application. than the data will pass our core bussines logic and will pass throw to some other external mechanism that will be our driven Adapter that coulbe a database, a message queue etc.

Most used/known software architectures.

Hexagonal Architecture (a.k.a. Ports and Adapters) by Alistair Cockburn and adopted by Steve Freeman, and Nat Pryce in their wonderful book Growing Object Oriented Software
Onion Architecture by Jeffrey Palermo
Screaming Architecture from a blog of mine last year
DCI from James Coplien, and Trygve Reenskaug.
BCE by Ivar Jacobson from his book Object Oriented Software Engineering: A Use-Case Driven Approach

Clean Architecture

Entities

Entities encapsulate the business rule. So it can be a set of data structures and functions or a object with methods, it does't really matter as long as the entities could be used by many different applications in the enterprise.
They are the least likely part of the system that will change when something external changes, so no operational change to any particular application should affect the entity layer.

Use Cases

This layer will be responsible for application-specific business rules.
It encapsulates and implements all of the use cases of the system. This will coordinate the data flow to and from the entities, and direct those entities to use their business rules to achieve the goals of the use case.
We also expect tha this layer will not be affected by exertnal changes like database, UI or other frameworks.

Interface Adapters

This layer is a set of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or the Web.
For example this layer will contain all the MVC architecture of a GUI
This layer will be responsable to convert the data from the form most convenient for entities and use cases, into the form most convenient for whatever persistence framework is being used. All the SQL related stuffs should be restricted to this layer too.

Frameworks and Drivers / Outermost layer

This layer is generally composed of frameworks and tools for example the Database, the Web Framework, etc. Normaly you will not write much code here other than make the conections for the code communicates to the next circle inwards.

Specifics

The main concern on the clean architecture is the separation of concerns. You can achieve that by dividing the software into layers, each has at least one layer for business rules, and another for interfaces.
Some get there the software will have to be
- Independent of Frameworks. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.
- Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element.
- Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
- Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
- Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world. source/credits

Software Design

Software design is the process in the development which creates a specification of a software artifact, intended to accomplish goals.
Software design usually involves problem solving and planning a software solution. This includes both low-level component and algorithm design and high-level, architecture design.

Software Design is importante because it focus on the specification of software artifact that will help to developers to implement the software following the pattern and so maintaining a more organized development

Questions

Main diferences between Software architecture and Software design
- Architecture: A higher vision about the system. Focus on the fundamental structures of the system.
- Design: Low level view of the system. Focus on the specification of software artifact which will help to developers to implement the software.

References:

Who Needs an Architect? - https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Architecture - https://martinfowler.com/architecture/
The Clean Code Blog / The Clean Architecture - https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Solid Principles

Victor Hugo Grabowski Beltramini — Mon, 21 Feb 2022 23:28:35 +0000

SOLID
- Single Responsibility Principle
- Open Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle

Single Responsibility Principle

Each class should be responsible for a single part or functionality of the system.

Benefits
- Testing – A class with one responsibility will have far fewer test cases.
- Lower coupling – Less functionality in a single class will have fewer dependencies.
- Organization – Smaller, well-organized classes are easier to search than monolithic ones.

Open Closed Principle

Software components should be open for extension, but not for modification

Benefits
- Less Bugs - We stop ourselves from modifying existing code and causing potential new bugs in other parts of the system that could be using that part of code that we modify

Liskov Substitution Principle

Objects of a superclass should be replaceable with objects of its subclasses without breaking the system. In other words the Liskov Substitution Principle (LSP) applies to inheritance hierarchies such that derived classes must be completely substitutable for their base classes.

Benefits
- Code re-usability
- Reduced coupling
- Easier maintenance

Interface Segregation Principle

No client should be forced to depend on methods that it does not use. In other words you should not use a hierarchie of a classe that you do not need all of his propriets or methods. To do that larger interfaces should be split into smaller ones. So, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them.

Benefits
- Readability and Maintainability of the code because we reduce our classes implementation only to required actions that we need without any additional or unnecessary code.

Dependency Inversion Principle

High-level modules should not depend on low-level modules, both should depend on abstractions. Our code should depend on abstractions (interfaces and abstract classes) instead of concrete implementations (classes). The abstractions should not depend on details; instead, the details should depend on abstractions.

Benefits
- Flexibility and Stability at the level of the entire architecture

References

A Solid Guide to SOLID Principles - https://www.baeldung.com/solid-principles
What are the SOLID principles in Java? - https://www.educative.io/edpresso/what-are-the-solid-principles-in-java
SOLID in C#: The Single Responsibility Principle - https://exceptionnotfound.net/simply-solid-the-single-responsibility-principle/